== Bash is letting locales destroy shell scripting (at least on Linux)

Here, let me present you something in illustrated form, on a system
where _/bin/sh_ is Bash:

.pn prewrap on

 $ cat Demo
 #!/bin/sh
 for i in "$@"; do
   case "$i" in
     *[A-Z]*) echo "$i has upper case";;
   esac
 done
 $ env - LANG=en_US.UTF-8 ./Demo a b C y z
 b has upper case
 C has upper case
 y has upper case
 z has upper case
 $ env - LANG=en_US.UTF-8 /bin/dash ./Demo a b C y z
 C has upper case
 $ env - ./Demo a b C y z # no locale
 C has upper case
 $

I challenge you to make sense of either part of Bash's behavior
in the ``en_US.UTF-8'' locale. 

([[Contrary to my initial tweet
https://twitter.com/thatcks/status/484441189958320128]], this
behavior has apparently been in Bash for some time. It's also
somewhat system dependent; Bash 4.2.25 on Ubuntu 12.04 behaves this
way but 4.2.45 on FreeBSD doesn't.)

There is no two ways to describe this behavior: this is braindamaged.
It is at best robot logic on Bash's part to allow _[A-Z]_ to match
lower case characters.  It is also terribly destructive to bash's
utility for shell scripting.  If I cannot even count on glob
operations that are not even in a file context operating sanely,
why am I using bash to write shell scripts at all? On many systems,
this means eschewing '_#!/bin/sh_' entirely because (as we're seeing
here) _/bin/sh_ can be Bash and Bash will behave this way even when
invoked as _sh_.

(I have to assume that not matching _a_ as upper case is a Bash
bug but that the rest of the behavior is intended. It makes more
sense than the other way around.)

What Bash has done here is to strew land mines in the way of my
scripts working right in what is now a *common* environment. If I
want to continue using shell scripts I have to start trying to
defensively defeat Bash. What will do it? Today, probably setting
((LC_COLLATE=C)) or better yet ((LC_ALL=C)). In all of my scripts.
I might as well switch to Python or Perl even for small things;
they are clearly less likely to cause me heartburn in the future
by going crazy.

There's another problem with this behavior, which is that it is not
what any other POSIX-compatible shell I could find does (on Ubuntu
14.04). Dash (the normal _/bin/sh_ on many Linuxes), mksh, ksh, and
even zsh don't match here. This means that having Bash as _/bin/sh_
creates a serious behavior difference, not just adds non-POSIX
features that you may accidentally (or deliberately) use in
'_#!/bin/sh_' scripts.

(Yes, yes, [[I've written about this before ../sysadmin/LANGHate]].
But the examples back then were vaguely sensible things for locales
to apply to. What is happening in the _Demo_ script is very, very
far over the line. What is next, GNU _grep_ deciding that your
'_[A-Z]_' should match case-independently in some locales? That's
just as justified as what Bash is doing here.)

PS: This is actually making me rethink the idea of having _/bin/sh_
be Bash on our Ubuntu machines, which is the case for [[historical
reasons ../unix/PortableShThreeUnixes]]. The pain of rooting out
bashism from our scripts may be less than the pain of dealing with
Bash braindamage.

=== Sidebar: the bug continues

If you change the _[A-Z]_ to _[a-z]_ and try _Demo_ with all upper
case letters, it will match A-Y but think _Z_ doesn't match. This
is symmetrical in what you could consider a weird way. A quick test
suggests that all other letters besides '_a_' (in the [A-Z] case)
and 'Z' (in the [a-z] case) match 'correctly', if we assume that a
case independent match is correct in the first place.

Because I was masochistic tonight this has been filed as [[GNU Bash
bug 108609 http://savannah.gnu.org/support/index.php?108609]] (tested
against bash git tip), although savannah.gnu.org may have eaten the
actual text I put in (it sent the text to me in email but I can't
read the text through the web). My bug is primarily to report the
missing 'a' and 'Z' and only lightly touches on the whole craziness
of [A-Z] matching any lower case characters at all, so I encourage
other people to file their own bugs about that. I have opted for a
low-stress approach myself since I don't expect my bug report to go
anywhere.