[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unexpected behavior observed when using address@hidden/pattern/strin
Re: Unexpected behavior observed when using address@hidden/pattern/string} construct
Tue, 16 Jan 2007 11:45:06 -0500
> > Note that the goal in the examples below is to prepend "-iname '" (portion
> > within double quotes only) to each of the 2 elements in the original array,
> > without changing the number of words. i.e., the new array should contain the
> > following 2 words:
> > -iname 'abc
> > -iname 'def
Thanks for your careful analysis and detailed description of the problem.
With that information, I have been able to fix the bugs reported in your
In the meantime, you can use
eval a2="address@hidden/#/"-iname '"}"
to get the behavior you want.
I apologize for the delay; the demands on my time are such that I do not
generally respond to bug reports until I have had a chance to investigate
> The posix section on "double-quotes" requires that both single and double
> quotes be balanced within the rhs of the parameter construct. This at least
> implies that something akin to single and double quoted strings are permitted
> within the parameter replacement. However, both the examples I have tried and
> inspection of param_brace_expand_rhs indicate that if the entire parameter is
> within double quotes, nested quotes don't really begin a nested string. The
> rhs is parsed as a double quoted string in which unquoted double quotes are
> simply discarded, and single quotes are retained literally. The only reason I
> can see for using double quotes within the replacement is to allow an
> unbalanced single quote to appear in the rhs. Single quotes themselves are not
> treated specially at all. This begs the question: If single quotes are not
> special within the rhs of a double quoted parameter construct, why are they
> required to be balanced? Perhaps it is to allow the same rule to be applied to
> the case of double-quoted and non-double-quoted parameter constructs?
It's much simpler (and more complicated) than that. The Posix rule is intended
to allow the historical Bourne shell double-quoted string parsing, which, to a
great extent, is maintained in the Korn shell. The Bourne shell has a single
quoting context, regardless of whether or not it's parsing a parameter
expansion within braces. A double quote within the braces terminates a
double-quoted string begun outside the braces.
Bash, on the other hand, begins a new quoting context inside braces. Single-
and double-quoted strings are recursively parsed according to the appropriate
However, there is a catch: we have to deal with the sh parsing artifact.
That is the reason for the `stripdq' argument to string_extract_double_quoted
and the immediate call to that function in parameter_brace_expand_rhs. It
took a long time and lot of experimenting to get that "right enough".
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU address@hidden http://cnswww.cns.cwru.edu/~chet/