Re: Using -prune option of find to ignore hidden directories

[Greg Wooledge <wooledg@eeg.ccf.org>]

On Thu, May 04, 2017 at 09:36:11AM +0200, Nicolas George wrote:
> Note that it is a severe misfeature of the shell to have a very
> different behaviour when a glob matches than when a glob does not match.
> 
> I have seen make commands fail because they contained unquoted "[a]"
> arguments and someone just created a temporary file named a.
> 
> Fortunately, zsh fixes that: a glob that does not match either produce
> an error or expand to an empty list.

Bash has an option for this behavior (nullglob).  It's off by default
because it produces extremely surprising results in interactive use.
Most of the traditional Unix commands are designed around the standard
shell behavior of expanding a glob if possible, but leaving it untouched
if it matches nothing.

For example, rm(1):

$ rm *.txy
rm: cannot remove '*.txy': No such file or directory

rm expects an expanded list of pathnames, and tries to remove each of
them.  If one of them can't be removed, then it writes the argument
as part of the error message, so you know which one it couldn't remove.
With an unmatched glob, the glob itself is passed as the argument, so
rm can include it in the error message.

If you turn on nullglob, the unmatched *.txy glob simply vanishes,
and you end up executing rm with no arguments at all:

$ shopt -s nullglob
$ rm *.txy
rm: missing operand
Try 'rm --help' for more information.

This is slightly confusing, but you might think "Hey, I can live with
that."

But then there is ls(1).

If ls is invoked with no arguments, it lists the entire current working
directory.

$ shopt -u nullglob
$ ls *.txy
ls: cannot access '*.txy': No such file or directory
$ shopt -s nullglob
$ ls *.txy
0400_0001.pdf
1
11412687.html
11412687.pdf
[...]

So, I really would not endorse the use of nullglob in interactive shells.
Even in a script, you must use it with caution.