Wildcard expansion can fail with nonprinting characters

[Geoff Kuenning]

Version:

GNU bash, version 4.4.23(1)-release (x86_64-suse-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

Behavior:

If a pathname contains nonprinting characters, and is expanded 
from a variable name, wildcard expansion can sometimes fail.

Example (with actual nonprinting characters):

$ mkdir /tmp/test$'\361'dir
$ touch /tmp/test�dir/foo
$ ls /tmp/test�dir/f*
/tmp/test?dir/foo
$ x=/tmp/test�dir
$ echo "$x" | cat -v
/tmp/testM-qdir
$ ls "$x"/f*
ls: cannot access '/tmp/test'$'\361''dir/f*': No such file or 
directory

(Note: in the above example, I completed the "ls" line and 
generated x by using tab completion.  However, the bug happens 
even if the variable is set by other means, such as from the 
output of a script that generates the nonprinting pathname.)

Example repeated, with nonprinting character replaced with M-q in 
case mailers mangle them:

$ mkdir /tmp/test$'\361'dir
$ touch /tmp/testM-qdir/foo
$ ls /tmp/testM-qdir/f*
/tmp/test?dir/foo
$ x=/tmp/testM-qdir
$ echo "$x" | cat -v
/tmp/testM-qdir
$ ls "$x"/f*
ls: cannot access '/tmp/test'$'\361''dir/f*': No such file or 
directory

Expected behavior: ls with "$x/*" should list foo in both cases.

Observed behavior: when foo is accessed via variable substitution, 
the wildcard is not expanded.

Other comments: I've observed similar behavior with tab expansion 
and complex pathnames that contain "surprising" characters such as 
parentheses, spaces, and nonprinting characters, but I'm not sure 
whether it's related.
--
   Geoff Kuenning   geoff@cs.hmc.edu 
   http://www.cs.hmc.edu/~geoff/

The major difference between a thing that might go wrong and a 
thing
that cannot possibly go wrong is that when a thing that cannot
possibly go wrong goes wrong it usually turns out to be impossible 
to
get at or repair.
               -- Douglas Adams