Re: possible bug in zsh glob

["Nadav Har'El" <nyh@xxxxxxxxxxxxxxxxxxx>]

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?

Nadav.

-- 
Nadav Har'El                        |     Wednesday, Feb 24 2010, 10 Adar 5770
nyh@xxxxxxxxxxxxxxxxxxx             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |A fanatic is one who can't change his
http://nadav.harel.org.il           |mind and won't change the subject.