96

In most shells nullglob isn't the default. That means, for example, if you run this command

ls *

in an empty directory, it will expand the * glob to a literal *, instead to an empty list of arguments. There are ways to change that behaviour, so that * in an empty directory will return an empty list of arguments, which would seem more intuitive.

So, is there a reason why nullglob is disabled by default? If so, what is that reason?

Dakkaron
  • 1,997
  • 2
  • 16
  • 25
  • 32
    Somebody once made a bad choice that turned into "we've always done it this way". A very ubiquitous phenomenon (not only) in the software world. – Petr Skocik May 21 '15 at 12:27
  • Yeah, I kinda thought so, but is there like an origin point or anything like that? Was there any original reason, or was that purely arbitrary? – Dakkaron May 21 '15 at 12:34
  • 4
    The original reason is that the nullglob option didn't exist back then. So to maintain backwards compatibility it must be disabled by default. – PM 2Ring May 21 '15 at 12:48
  • 3
    While it does not specifically mention the null glob, some history on globbing is provided by this answer: http://unix.stackexchange.com/a/136409/22724 – StrongBad May 21 '15 at 13:10
  • 4
    I get the impression some think it should be obvious that nullglob should be enabled by default. I don't think it's obvious. That expansions happen in the shell before command invocation means that expanding to nothing is a less intuitive behavior than the glob remaining unchanged. – kojiro May 21 '15 at 16:32
  • 4
    @kojiro Less intuitive to whom? Anyone with any familiarity with \*NIX shells knows that `*` is a glob and expands to all *existing* files; how is it "intuitive" for there to be a special case where empty directory globs are "expanded" to a literal `*`? – Kyle Strand Jul 05 '16 at 15:53
  • @KyleStrand because it isn't expanded to a literal `*`. It's just _not expanded_. – kojiro Jul 05 '16 at 15:54
  • 1
    @kojiro That's why I put "expanded" in quotes. The point is, when working with these shells, we come to expect that `*` will be expanded in a file-name context, unless it's escaped or appropriately quoted. The fact that this expansion doesn't occur in a specific context is a special case and therefore *not intuititive*. – Kyle Strand Jul 05 '16 at 15:57
  • @KyleStrand First, please understand that I'm not actually arguing whether or not nullglob is intuitive. I'm arguing that it's not _obvious_ that nullglob should be _on by default_. That is, it is not obvious that a historical default should be changed, especially in such a ubiquitous shell that (like it or not) has to track POSIX to some degree. – kojiro Jul 05 '16 at 16:02
  • @kojiro You said (in your comment immediately before mine, to which I was responding): "...expanding to nothing is less intuitive behavior than the glob remaining unchanged." Hence my question: less intuitive to whom? I understand the historical argument, and the accepted answer (and my comment below it) have some good practical reasons for not having it on all the time. So I'm not arguing that you're wrong about whether or not the default should be changed; I'm just asking for clarification about your specific comment that the empty-expansion behavior would be "less intuitive". – Kyle Strand Jul 05 '16 at 16:09
  • @KyleStrand There's a bit to it, probably too much for the comments section. Chat? – kojiro Jul 05 '16 at 16:12
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/42053/discussion-between-kojiro-and-kyle-strand). – kojiro Jul 05 '16 at 16:14
  • why on earth would any one write `ls *` instead of `ls`? – phuclv Jun 07 '21 at 07:47
  • @phuclv Because it is a very simple example of globbing. Could have used `cat` or any other tool as well, but this question was about globbig, not about `ls`. Also, in this very case, running `ls *` in an empty directory, actually results in a different result as `ls`. Or if you want to stick to `ls` and have a more realistic result, instead try `ls *.txt`. – Dakkaron Jun 07 '21 at 13:22

1 Answers1

107

The nullglob option¹ would not be ideal in a number of cases. And ls is a good example:

ls *.txt

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)

With 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 txt file.

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 ash, AT&T ksh or zsh, 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 zsh, fish or 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 zsh with set -o cshnullglob though a more sensible way to do it in zsh would be to use a glob like:

ls -- *.(txt|html)

In zsh and 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).

Versions of 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 for, set or count.

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 $1, $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 /etc/glob if $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:

pattern='a.*b'
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 rc/ zsh / fish...).

¹ added in 2.0 in 1996 with the introduction of the shopt builtin, named after zsh's equivalent option, though bash had the allow_null_glob_expansion variable for that in earlier versions

² 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 shopt

Stéphane Chazelas
  • 522,931
  • 91
  • 1,010
  • 1,501
  • There's another usability issue: `nullglob` appears to break tab-completion (pressing the tab key does nothing when it's enabled). – Kyle Strand Jul 05 '16 at 16:01
  • 1
    It's possible to use nullglob on a _per glob_ basis with bash - although the syntax is not as elegant as zsh `files=$(shopt -s nullglob;echo *.txt)` – Jon Nalley Sep 21 '17 at 21:33
  • 7
    @JonNalley, that stores the concatenation (with space) of the file names (with possible transformation with `xpg_echo`) into a _scalar_ variables. You'd need something like `readarray -td '' files < <(shopt -s nullglob; printf '%s\0' *.txt)` with `bash` 4.4 or above or `(shopt -s nullglob; printf '%s\0' *.txt) | xargs -r0 cmd` with GNU `xargs` for that to be usable at all with arbitrary file names. Or, still with bash4.4, use a helper function that uses `local -` (copied from ash 25 years later) for a local scope for options. – Stéphane Chazelas Sep 22 '17 at 07:31
  • These [docs](https://www.gnu.org/software/bash/manual/html_node/Filename-Expansion.html) are very useful for precise definitions of what Bash does when expanding globs, including while nullglob and failglob are set/unset. – SpinUp __ A Davis May 06 '22 at 20:44