Date:        Thu, 12 Apr 2018 12:10:04 -0700
    From:        Don Cragun <dcra...@sonic.net>
    Message-ID:  <b89ff100-6a79-4ade-9cc2-02973bd28...@sonic.net>

  | The fact that the $ is special is what is the key.

The problem is in the interpretation of just what "treated literally" means.

If it just means that "the character is itself and is not transformed into
something else" that's fine, the special $ inside the "" (which is not
treated literally, so it remains the introducer of various expansions)
can then look at the following character, see it is a '{' (untransformed)
and then go on and implement parameter expansion as you describe
-- and the various other characters that have meaning in that,
such as ':' '-' '+' '?' '%' '#' '=') which (being treated litterally all
represent themselves) can be part of the syntax.

On the other hand, if "treated literally" means "is itself and can have
no meaning or other interpretation other than being the character
itself" then that '{' must just be a '{' that is part of the string, and not
be co-opted into being part of the sh syntax for parameter expansions.

I am assuming here that the first interpretation is the desirable one.

Given that, then the "treated literally" '-' in the double quoted (or for
that matter single quoted) string inside a character class, is just a
'-' character, but that can still (as the '{' was in the parameter expansion)
be used as a syntax character in the class - indicating the range,
whether it was double quoted or not.

On the other hand, if you want the '-' to always represent the character
'-' itself, and not be part of the range expression, and you want to produce
that result just from the words "treated literally", you have to define
"treated literally" in the second form, and in that case, the '{' in the
"${..." form cannot be the '{' that is part of the parameter expansion.

It cannot be both ways.


But let me be clear about something - my point here is not to argue
for changes to all of the shells to meet some bizarre interpretation of
the specification, it is that the text in the standard needs to be improved,
and be explicit about things like this.

That it is possible for me to make an even semi-plausible argument in
this way means the text does not state the intentions nearly clearly
enough, and needs to be made much more precise.

There is a temptation for those who know what it should mean to read
the text, and see that it can mean what it should mean (and perhaps
not even notice that things could be interpreted differently) and then
be happy that all is OK.    But when read by someone who has no idea
what the desired outcome is, and has only the words to reply upon,
we must be sure that there is no room at all for misinterpretation.

This is why standards are generally very dry, hard to read, and boring
documents - they need to be precise about every little detail (and yes,
saying something is unspecified or undefined is precise, provided it
is clear what the "something" is).

When 985 is revisited, and the wording for how pattern matching is done
gets revised, just specify all of this precisely - it does not need to be in the
form of some algorithm to achieve the desired result (although that is one
method) but it must make it absolutely clear what the desired result is,
for every possible input.

kre

Reply via email to