[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
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
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
the respective top-level rules.) I wonder whether anyone has ever
idea of supporting a `compatible' option, which would determine whether
shell compatibility is required in such contexts. With such an option, one
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.
``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/