Re: [A-Z], [:upper:]

[Robert Elz]

    Date:        Thu, 28 Mar 2019 17:27:24 -0400
    From:        Greg Wooledge <wooledg@eeg.ccf.org>
    Message-ID:  <20190328212724.aczkwjoyceeg6rnf@eeg.ccf.org>

  | You have two problems here.  Well, four really.

2 really, I think...

  | First, your first example invokes platform-defined behavior.

Technically, yes ... though unless something points to it being a
locale problem (eg: if the example code and shell seem to peform
flawlessly for everyone else) I think it is reasonable to assume the
C locale (aka POSIX) locale for anything which doesn't say otherwise.

And even ignoring that:

  | [A-Z] isn't safe to use unless ...

That's true to an extent, but we know here that the intent is to
match 'C' which is between A and Z in every locale in the universe.
Variations on A might not be, variations on Z might not be, and there
might be more than just the upper case English letters between A and Z,
included in the ragne (even including things which are not letters at
all, upper case or not, and lower case chars might be included) but we
can assume that for any real locale, 'C' will be in that range (real as
being one in use in the world, rather than one invented for the very
purpose of not including C in the collating sequence between A and Z)

So I think that problem can be overlooked/ignored.


  | Second, your second example should be using [[:upper:]] not [:upper:].
  | You might be mixing up tr's syntax with glob/regex syntax.

This, of course, is the real problem, and is (almost) all that really needed
saying.

My question however is this part from the original report:

        In version 4 [A-Z] is broken and [:upper:] works.
        In version 5, the situation is reversed.

I don't see that (though in 4.4-something, rather than 4.3) and given
the nature of the problem (incorrect usage), I don't understand how it
is possible.  I see the same results in both versions (with both the
correct and incorrect usage).   Unless...

But because of that:

  | Also, you didn't tell us what result you got, or what result you
  | expected to see.

This is also important.   Giving actual in and out examples, cut
and pasted from a real test run - however the cut/paste is done, doing
the test with -x and directing stdout/stderr to a file, and including
the file is one way, using "script" and including the typescript file
is another, or cut/paste from an xterm (or any xxxterm) is another.
(even including a jpeg of a photo of a screen image can work - though
please, only as a last resort!)

But everyone, please, never re-type the code/results in any bug-report -
that almost always leads to problems, eg: if that was done here, and the
missing [] pair were simply forgotten in the bug report, but had been
used in the actual test.    Then whatever is actually going wrong is
something different, but without knowing what that is, no-one can
possibly help.

  | And you forgot to quote.

Really!   That again!   Here, unless one of A or B (or perhaps C,
though as that's supposed to be removed, it shouldn't matter) is in
IFS - in which case I think we'd be told - quoting makes no difference
at all.

Regardless of your views on the subject, not everything needs to be
quoted.   Quoting expansions where the content is unknown and the
intent is for it to remain unchanged is the right thing to do.  When
the content of the variable is known, though it really is optional,
and sometimes even wrong to quote.

Failing do so in a test like this is not an issue at all.

kre