> 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 _______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
