bug-bash
[Top][All Lists]
Advanced

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

Re: Unexpected behavior observed when using ${parameter[@]/pattern/strin


From: Chet Ramey
Subject: Re: Unexpected behavior observed when using ${parameter[@]/pattern/string} construct
Date: 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
message.

In the meantime, you can use 

eval a2="${a[@]/#/"-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
them.

                [...]

> 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
rules.

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".

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                       Live Strong.  No day but today.
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/




reply via email to

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