Re: Re: possible bug in zsh glob

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.

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

[Bart Schaefer]

On Dec 22,  9:48pm, Nikolai Weibull wrote:
}
} Why does $'...' not expand inside "..."?

Because it doesn't in any of the shells that introduced it before
zsh had it.

I believe the reasoning is that double-quote is allowed to appear
inside $'...' and to expand $'...' inside double-quotes creates a
parsing conflict.  "How does this $'with " embeded' parse?"

} It's not, as far as I can tell, mentioned in the documentation.

The documentation for zsh tends to omit things that are assumed
knowledge, particularly when a concept or feature originates from
another source -- because if you didn't already know about it from
the original source, why did you even think to use it?

This is an acknowledged shortcoming that is addressed piecemeal.