On Wed 08 May 2019 at 14:08:03 (+0800), KHMan wrote: > > On Tue 07 May 2019 at 10:12:10 (+1000), David wrote: > > > On Mon, 6 May 2019 at 23:53, Erik Christiansen wrote: > > > > On 06.05.19 09:03, Greg Wooledge wrote: > > > > > On Sat, May 04, 2019 at 01:48:01PM +0200, Jonas Smedegaard wrote: > [snipped all] > > > Hi Erik > > > > > > Maybe you would enjoy answering this question then? > > > https://lists.gnu.org/archive/html/help-bash/2019-05/msg00000.html
> Running the result of a command execution and allowing the result to > control delimiters, dropping out of the string? Now that gives me the > jeebies, security-wise. :-) I think you can heave a sigh of relief as I think I can show that's not happening after all. The trick is to add set -x to the top of the script (and I've set -v as well). It does appear (I think) that the contents of the backquotes are interpreted earlier than my working showed: $ bash bash-bit echo + echo echo "[` echo \" \x \\x \\\x \\\\x \\" \\\" \" `]" ++ echo ' \x \x \x \x " " ' + echo '[ \x \x \x \x " " ]' [ \x \x \x \x " " ] echo + echo echo "[` echo \" \\" \\\" \\\\" \" `]" bash-bit: command substitution: line 6: unexpected EOF while looking for matching `"' bash-bit: command substitution: line 7: syntax error: unexpected end of file + echo '[]' [] echo + echo # $ But I'm not sure how to distinguish the order of the interpretation of \\ and \" in the above. > I have since been studying the bash sources, and posted another query > yesterday, see: > > http://lists.gnu.org/archive/html/help-bash/2019-05/msg00006.html > > To summarize, consider our usual examples: > echo "[` echo \" \\" \" `]" A # [ " ] A > echo "[` echo \" \\x \" `]" J # [ \x ] J > > Here's a theory: Inside the inner backquotes, \" gets escaped into " > because token processing sees the current delimiter as ". (But matched > pair processing sees the inner delimiters as ``.) The \\" becomes \" > and the \\x becomes \x. The inner commands are then run as: > > echo " \" " > echo " \x " I follow that. Unfortunately, set -x appears not to show the raw line in that state, but interprets those outer double quotes and then reports the line in its own single quotes. > giving the expected result. When entering the matched pair processing > function for the inner ``, the delimiter stack was not updated, so the > token function still sees the current delimiter as the outer one, > which is ". So again it appears to involve the order of interpretation. > This is based on what I have studied in the sources, and it doesn't > make any sense to me from a syntax point-of-view, so I hope I can > eventually get a useful and definitive answer from the bash > maintainers. Is backquote deprecated yet? :) I saw Greg's followup to your new post; it seems mainly aimed at outlawing overlapping strings and allowing only nested ones. I guess, then, that that does prevent delimiting a string by a quote from one level paired with one "dropping out of" (returned by) the inner command. Cheers, David.
# set -x -v echo echo "[` echo \" \x \\x \\\x \\\\x \\" \\\" \" `]" echo echo "[` echo \" \\" \\\" \\\\" \" `]" echo #
