nullglob option (which BTW is a
zsh invention, only added years later to
2.0)) would not be ideal in a number of cases. And
ls is a good example:
Or its more correct equivalent:
ls -- *.txt
(to list the contents of the non-hidden directories whose name ends in
.txt, or the non-directory files with the same name patterns)
nullglob on would run
ls with no argument which is treated as
ls -- . (list the current directory) if no files match, which is probably worse than calling
ls with a literal
*.txt as argument¹.
You'd have similar problems with most text utilities:
grep foo *.txt
Would look for
foo on stdin if there's no
A more sensible default, and the one of csh, tcsh, zsh or fish 2.3+ (and of early Unix shells) is to cancel the command altogether if the glob doesn't match.
bash (since version 3) has a
failglob option for that (interesting to this discussion, since contrary to
bash doesn't support local scopes for options², that option when enabled globally does break a few things like the bash-completion functions).
Note that csh and tcsh are slightly different from
bash -O failglob in cases like:
ls -- *.txt *.html
Where you need all the globs to not-match for the command to be cancelled. For instance, if there's one txt file and no html file, that becomes:
ls -- file.txt
You can get that behaviour with
setopt cshnullglob though a more sensible way to do it in
zsh would be to use a glob like:
ls -- *.(txt|html)
ksh93, you can also apply nullglob on a per-glob basis, which is a lot saner approach than modifying a global setting:
files=(*.txt(N)) # zsh
files=(~(N)*.txt) # ksh93
would create an empty array if there's no
txt file instead of failing the command with an error (or making it an array with one
*.txt literal argument with other shells).
fish prior to 2.3 would work like
bash -O nullglob but give a warning when interactive when a glob has no match. Since 2.3, it works like
zsh except for globs used in
Now, on the history note, the behaviour was actually broken by the Bourne shell. In prior versions of Unix, globbing was done via the
/etc/glob helper and that helper behaved like
csh: it would fail the command if none of the globs matched any file and remove the globs with no match otherwise.
So the situation we're in today is due to a bad decision made in the Bourne shell.
Note that the Bourne shell (and the C shell) came with another new Unix feature: the environment. That meant variable expansion (it's predecessor only had the
$2... positional parameters). The Bourne shell also introduced command substitution.
Another poor design decision of the Bourne shell was to perform globbing (and splitting) upon the expansion of variables and command substitution (possibly for backward compatibility with the Thompson shell where
echo $1 would still invoke
$1 contained wildcards (it was more like pre-processor macro expansion there, as in the expanded value was parsed again as shell code)).
Failing globs that don't match would mean for instance that:
grep $pattern file
would fail the command (unless there are some
a.whateverb files in the current directory).
csh (which also performs globbing upon variable expansion) does fail the command in that case (and I'd argue it's better than leaving a dormant bug there, even if it's not as good as not doing globbing at all like in
¹ for which
ls would likely report an error that the
*.txt file doesn't exist, unless it has been created in the interval, or the current directory happens to be searchable but not readable and that file or directory exists. Try after
mkdir -p '*.txt/wtf'; chmod a=,u=wx . for instance
² version 4.4 saw some improvement on that front in that options set by
set -o could be made local to functions with
local - like in the Almquist shell, but that doesn't work for
bash's second set of options, the ones set with