bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: quoting inside backquotes in 3.1


From: Eric Blake
Subject: Re: quoting inside backquotes in 3.1
Date: Sun, 05 Mar 2006 22:14:31 +0000

> This is how I interpreted POSIX's requirement that quoted strings
> inside backquotes be recursively processed:

My interpretation differs from yours, in order to match traditional behavior.

> 
> "While processing the characters, if instances of expansions or quoting
> are found nested within the substitution, the shell shall recursively
> process them in the manner specified for the construct that is found."

I take this to mean that the entire backtick word is parsed recursively
according to the rules specified for backticks, which are listed later on as:

"Within the backquoted style of command substitution, backslash shall
retain its literal meaning, except when followed by: '$', '`', or '\' (dollar
sign, backquote, backslash). The search for the matching backquote
shall be satisfied by the first backquote found without a preceding
backslash; during this search, if a non-escaped backquote is encountered
within a shell comment, a here-document, an embedded command
substitution of the $( command) form, or a quoted string, undefined
results occur. A single-quoted or double-quoted string that begins,
but does not end, within the "`...`" sequence produces undefined results."

I take this to mean that all " encountered inside the `` are preserved
literally as the basis of input to the command-substitution subshell,
without regards to recursive double-quoted string parsing (unlike
$() command substitution).  After the end of the `` is found, then only
the \ preceding \, `, or $ are stripped, and all remaining characters
are fed to the subshell performing the command substitution.  It is at
that point, in the subshell, where double-quoted strings must be
properly terminated for predictable results (although some older shells
supplied the missing closing quote rather than causing a syntax error).
In the sample that started this thread, the subshell sees three double
quotes, but the middle one is preceeded by a backslash, which forms
a valid double quoted string.

> 
> The double-quoted string is processed, the backslash quotes the
> succeeding backslash, the second double quote terminates the quoted
> string, and we are left with a syntax error.

I disagree that this is a syntax error.  Double-quoted strings are
not parsed recursively inside ``, rather, the double quotes are
collected literally as characters into the subscript.  Double-quoted
strings are only parsed recursively inside $() command substitution,
which requires a valid shell script (which is one of the reasons that
$() is so much nicer than ``).

> 
> This POSIX requirement may be new -- I didn't analyze previous shell
> implementations -- but its intent seems to be to allow embedded quoted
> strings to contain backquotes (for instance).

To have a \ inside of ``, you quote the backslash with an additional
backslash.   The only construct recursively parsed inside of `` when
searching for the terminating ` are the constructs \\, \`, and \$.

> 
> I will see if I can find a way to preserve backwards compatibility.
> 

-- 
Eric Blake




reply via email to

[Prev in Thread] Current Thread [Next in Thread]