What do you think of adding a way to warn script writers/runners that
there is an unquoted glob like [:blank:] that is obviously intended
to be quoted, but that will work almost all of the time. Until someone
expands it in a directory containing a file with one of these
single-letter file names: ":" "b" "l" "a" "n" "k".
If there were an option I could set globally, somehow,
to make all such scripts emit a warning or even to fail,
I would use it.
Why? Many scripts use erroneous commands like tr -dc [:alnum:]
that work just fine during testing, but then fail
mysteriously when run in a different directory just
because that morning a file named "a" was created.
There, the [...] is being interpreted as a shell "glob",
rather than as the intended tr character class. The per-application
fix is obviously to quote the argument: tr -dc '[:alnum:]'
But many don't ever notice the error until it's too late.
I added a similar safety net in GNU grep:
There, the proper syntax is '[[:blank:]]', yet many people mistakenly
used '[:blank:]'. Noticing the duplicate ":" in the character class,
with one at the beginning and one at the end, it's safe for grep to
diagnose the problem even in an otherwise-conforming implementation.
No one needs to include two ":" bytes in a grep [...] expression,
just as they never need to do that in a [...] glob.