[Top][All Lists]

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

Re: Unexpected behavior observed when using address@hidden/pattern/strin

From: Stahlman Family
Subject: Re: Unexpected behavior observed when using address@hidden/pattern/string} construct
Date: Mon, 29 Jan 2007 06:53:05 -0600

----- Original Message ----- From: "Chet Ramey" <address@hidden>
To: "Stahlman Family" <address@hidden>
Cc: <address@hidden>; <address@hidden>
Sent: Friday, January 26, 2007 5:36 PM
Subject: Re: Unexpected behavior observed when using 
address@hidden/pattern/string} construct

Stahlman Family wrote:

The result of all this is that for the "+", "-", and "=" parameter
constructs, nested double-quote pairs in the rhs are stripped, but for
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
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

I will consider it for a future version.  Thanks for the suggestion.

I appreciate your considering it.

   Brett Stahlman

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

reply via email to

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