Re: Shell game? was Re: pmount could perhaps be of greater utility?

[David Wright <deblis@lionunicorn.co.uk>]

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
#