Re: possible bug in zsh glob

[Matt Wozniski <godlygeek@xxxxxxxxx>]

On Wed, Feb 24, 2010 at 2:53 AM, Nadav Har'El <nyh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Feb 23, 2010, Andrey Borzenkov wrote about "Re: possible bug in zsh glob":
>> On Tuesday 23 of February 2010 19:13:02 dipakgaigole wrote:
>> > *************** bash **************
>> > bash-2.05b$ ls -l *.txt *.jp
>> > ls: *.jp: No such file or directory
>> [...]
>> > #ls -l *.txt *.jp
>> > zsh: no matches found: *.jp
>>
>> setopt no_nomatch
>>
>> to get the same behaviour as in bash.
>
> Amazing! This really surprised me. I was about to answer that, "no, zsh
> behaves exactly like bash in this respect, and the way it should", when I
> suddenly realized that many years ago I added "set +o nomatch" (equivalent
> to setopt no_nomatch you recommended) in my .zshrc, and since forgot about
> it :-)
>
> Is there any logical reason why zsh's default is the way it is? I.e., when
> it sees
>
> Â Â Â Âls -l *.txt *.jp
>
> And there are no *.jp, it has to stop the entire command, rather than let
> the command give you a message, like was always the case in the Bourne shell,
> ksh, and bash (without the failglob option)?
>
> I always consider what is now apparently the default zsh behavior to be
> annoying especially when you do a command like
>
> Â Â Â Âscp remote:*.c .
>
> and then the shell doesn't do it, and you need to go back and quote out the
> star. Why? What does this extra "beaurocracy" gain us? If the shell can
> just do "the right thing" by passing along the star, why shouldn't it?

Because the sh/ksh/default bash behavior is dangerous if you ever have
filenames containing shell metacharacters.  Consider a command like:

    rm [abc]

The sh/ksh/default bash behavior would be for that to delete any file
named either 'a', or 'b', or 'c', or, if there are no files with any
of those names, to delete the file named '[abc]'.  I, quite frankly,
find that nuts.  Not that the zsh behavior can't be annoying at times
- I'd prefer nonomatch for scp wildcards, for instance - but at least
the zsh behavior is safe.  It does what you tell it to, and aborts if
it can't.  The other shells do what you tell them to, but assume that
you told them to do the wrong thing if they can't.

~Matt