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 ge...@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
