possible bug in zsh glob

possible bug in zsh glob

[dipakgaigole]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

Hello,

I am finding this difference in the behavior while pattern matching.
Under Bash, it properly throws error for non matching pattern and shows the details of the matched pattern.

*************** bash **************
bash-2.05b$ pwd
/tmp
bash-2.05b$ ls -l *.txt *.jp
ls: *.jp: No such file or directory
-rw-r--r-- 1 dipak man 2 Feb 23 07:40 a.txt
-rw-r--r-- 1 dipak man 2 Feb 23 07:40 b.txt
-rw-r--r-- 1 dipak man 2 Feb 23 07:40 c.txt
bash-2.05b$
**********************************


Whereas under zsh 4.3.4, if any non-matching pattern is found, it also skips/ignores the matched pattern output.
************ zsh 4.3.4 ************
bash-2.05b$ ~/myzsh/bin/zsh-4.3.4 --version
zsh 4.3.4 (i686-pc-linux-gnu)
bash-2.05b$ ~/myzsh/bin/zsh-4.3.4
#pwd
/tmp
#ls -l *.txt *.jp
zsh: no matches found: *.jp
#set -o | grep -i glob
nobareglobqual off
nocaseglob off
cshnullglob off
extendedglob off
noglob off
noglobalexport off
noglobalrcs off
globassign off
globcomplete off
globdots off
globsubst off
kshglob off
nullglob off
numericglobsort off
shglob off
warncreateglobal off
#
**********************************

To me it looks like a bug. Does anyone has seen such behavior?

Thanks,
Dipak

Re: possible bug in zsh glob

[Mikael Magnusson]

please don't crosspost users and workers, all users messages are sent
to workers as well.

On 23 February 2010 17:13, dipakgaigole <dipakgaigole@rediffmail.com> wrote:
> Hello,
>
> I am finding this difference in the behavior while pattern matching.
> Under Bash, it properly throws error for non matching pattern and shows the details of the matched pattern.
>
> *************** bash **************
> bash-2.05b$ pwd
> /tmp
> bash-2.05b$ ls -l *.txt *.jp
> ls: *.jp: No such file or directory

You'll notice it's ls printing this message, not bash.

> Whereas under zsh 4.3.4, if any non-matching pattern is found, it also skips/ignores the matched pattern output.

This is by design, if you want the weird bash behaviour you can setopt
nonomatch.

-- 
Mikael Magnusson

Re: possible bug in zsh glob

[Andrey Borzenkov]

[-- Attachment #1: Type: Text/Plain, Size: 281 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: possible bug in zsh glob

[Nadav Har'El]

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@math.technion.ac.il             |-----------------------------------------
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.

Re: possible bug in zsh glob

[Andrey Borzenkov]

[-- Attachment #1: Type: Text/Plain, Size: 640 bytes --]

On Wednesday 24 of February 2010 10:53:52 Nadav Har'El wrote:
> 
> 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 guess, because it (zsh) originates more from csh.

Anyway, it is too late to change defaults now.

Personally I like to take it as indication that I made a typo in 
command. I do not have any problems with extra quoting when needed :)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: possible bug in zsh glob

[Matt Wozniski]

On Wed, Feb 24, 2010 at 2:53 AM, Nadav Har'El <nyh@math.technion.ac.il> 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

Re: Re: possible bug in zsh glob

[dipakgaigole]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

 

On Wed, 24 Feb 2010 13:36:09 +0530  wrote
>On Wednesday 24 of February 2010 10:53:52 Nadav Har'El wrote:
>> 
>> 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 guess, because it (zsh) originates more from csh.
>
>Anyway, it is too late to change defaults now.
>
>Personally I like to take it as indication that I made a typo in 
>command. I do not have any problems with extra quoting when needed :)
>

Before posting the question, I had a look at the glob options as well as the NOMATCH option, but the description of NOMATCH option was confusing.

This is the information from the zshoptions man page:
    NOMATCH (-3)



If a pattern for filename generation has no matches, print an error, instead 
of leaving it unchanged in the argument list.  This also applies to file 
expansion of an initial ~ or =.


Thanks for this info Andrey !!!

-Dipak

Re: ( Text in unknown character set UTF-8 not shown )

[Bart Schaefer]

On Feb 24, 10:56am, dipakgaigole wrote:
} 
} Before posting the question, I had a look at the glob options as well
} as the NOMATCH option, but the description of NOMATCH option was
} confusing.

The name of the option comes from a csh variable that can be set.  It
was therefore originally "nonomatch".  Many years ago, though, zsh
added the ability to turn *off* any option by prefixing its name with
an additional "no".  Eventually it was viewed as silly that one would
thus e.g. "setopt nononomatch"; so all the options that *already* had
a "no" prefix were renamed to drop one "no" and reverse their boolean
state (including, therefore, their default-at-startup boolean state).

In this case that left us with "nomatch" -- and the documentation also
had to be reversed, of course, which didn't always work as well as when
documenting the original name and state.

Re: possible bug in zsh glob

[Bart Schaefer]

On Feb 24,  7:00am, Bart Schaefer wrote:
} Subject: Re: ( Text in unknown character set UTF-8 not shown )

Er, sorry about that, the age of my email reader is showing.

For more reasonable archive threading:

On Feb 24, 10:56am, dipakgaigole wrote:
} 
} Before posting the question, I had a look at the glob options as well
} as the NOMATCH option, but the description of NOMATCH option was
} confusing.

The name of the option comes from a csh variable that can be set.  It
was therefore originally "nonomatch".  Many years ago, though, zsh
added the ability to turn *off* any option by prefixing its name with
an additional "no".  Eventually it was viewed as silly that one would
thus e.g. "setopt nononomatch"; so all the options that *already* had
a "no" prefix were renamed to drop one "no" and reverse their boolean
state (including, therefore, their default-at-startup boolean state).

In this case that left us with "nomatch" -- and the documentation also
had to be reversed, of course, which didn't always work as well as when
documenting the original name and state.