[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