Re: Unexpected behavior observed when using ${parameter[@]/pattern/string} construct

[Stahlman Family]

----- Original Message ----- 
From: "Chet Ramey" <chet.ramey@case.edu>
To: "Stahlman Family" <brettstahlman@comcast.net>
Cc: <bug-bash@gnu.org>; <chet@case.edu>
Sent: Friday, January 26, 2007 5:36 PM
Subject: Re: Unexpected behavior observed when using 
${parameter[@]/pattern/string} construct


> Stahlman Family wrote:
>
> > The result of all this is that for the "+", "-", and "=" parameter
> > expansion
> > constructs, nested double-quote pairs in the rhs are stripped, but for
> > patsub
> > constructs they are not. Is this difference by design?
>
> Yes.  The patsub construct is implemented as in ksh93.  When Dave put
> it into ksh, he decided that since Posix didn't standardize it, he was
> not constrained by their standardization of the historical Bourne shell
> behavior of nested quotes.  And so we have it today.

Ah. I see. I knew patsubs weren't part of the Bourne shell, but I wasn't aware of the Korn shell history. Should you ever have the 
time and/or inclination to implement the compability option, it would be nice to have all such nested double (and single) quoted 
strings parsed the same way, regardless of which of the various substitution constructs contained them. Ideally, they would be 
processed just as though they appeared at the top level, with the exception that a dollar_at construct would be handled like the 
corresponding dollar_star construct in a context expecting a string; i.e., whereas $* works like $@ in an unquoted top-level 
context, $@ would work like $* in a quoted non-top-level context. (I realize I may be oversimplifying a bit...)

> > Understood. (Provided that the phrase "the appropriate rules" does not
> > refer to
> > the respective top-level rules.) I wonder whether anyone has ever
> > floated the
> > idea of supporting a `compatible' option, which would determine whether
> > Bourne
> > shell compatibility is required in such contexts. With such an option, one
> > could put
> >
> > set +o compatible
> >
> > at the top of a script to enable a more natural form of nested string
> > processing.
>
> I will consider it for a future version.  Thanks for the suggestion.

I appreciate your considering it.

Thanks,
   Brett Stahlman

> 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/