Why is this happening in zsh?

Why is this happening in zsh?

[Anonymous]

I am moving away from Bash to zsh and I have one problem that keeps coming
up. Somehow zsh is interfering in interpreting commands and I know there
must be an option to stop this but I can't figure which one to use. An
example is

fossil --ignore *.class
zsh: no matches found *.class

fossil never receives the command at all

I also have problems sometimes with rsync and have to use Bash. zsh is
trying to substitute things that are supposed to be passed to the
command. How can I set zsh to always ignore these without breaking something
I haven't though of maybe like rm *.class

Re: Why is this happening in zsh?

[Heorhi Valakhanovich]

On Wed, 14 Mar 2012 19:59:02 +0100 (CET)
Anonymous <remailer@foo.asia-king.co.uk> wrote:

> 
> fossil --ignore *.class
> zsh: no matches found *.class
> 
> fossil never receives the command at all
> 

This happens in many command processors. I usually use quotes like

fossil --ignore "*.class"

This is not a solution but usual workaround.

Re: Why is this happening in zsh?

[Stephane Chazelas]

2012-03-14 19:59:02 +0100, Anonymous:
> I am moving away from Bash to zsh and I have one problem that keeps coming
> up. Somehow zsh is interfering in interpreting commands and I know there
> must be an option to stop this but I can't figure which one to use. An
> example is
> 
> fossil --ignore *.class
> zsh: no matches found *.class
> 
> fossil never receives the command at all
> 
> I also have problems sometimes with rsync and have to use Bash. zsh is
> trying to substitute things that are supposed to be passed to the
> command. How can I set zsh to always ignore these without breaking something
> I haven't though of maybe like rm *.class
> 

I think that maybe one thing you don't realise is the buggy
behavior of *other* shells.

Other shells do expand *.class as well before calling the
command, except that when *.class doesn't match any file, they
pass the string "*.class" unmodified to the application (and the
application will usually fail because they can't find a file
called "*.class", though in this very case I suspect it's the
other way round).

That is generally harmless, but in cases like:

rm -f [a-z]*.class

If there's no file matching that pattern, zsh will not run the
rm command, but other shells will tell rm to delete the file
called '[a-z]*.class' and since the [a-z]*.class pattern doesn't
match the '[a-z]*.class' file, that file may very well exist and
be deleted accidentally.

There are a number of options to change zsh behavior in that
regard, but I wouldn't do that.

In this very case, zsh behavior is helpful because it reminds you
that *.class is a globbing pattern and should be quoted if you
don't want it to be expanded (as I suspect). While in other
shells, *.class will silently be left untouched if there's no
class file in the current directory letting you overlook that
pending bug for when that script will be called from a
directory that has class files.

-- 
Stephane

Re: Why is this happening in zsh?

[Peter Stephenson]

On Wed, 14 Mar 2012 19:59:02 +0100 (CET)
Anonymous <remailer@foo.asia-king.co.uk> wrote:
> fossil --ignore *.class
> zsh: no matches found *.class

  setopt nonomatch

fixes this.

If you are generally speaking expecting bash-like behaviour you might
want to read the zshoptions manual page and note in particular options
that are marked <S> (on in sh emulation) or <Z> (on by default in zsh
but not necessarily emulations of other shells.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Why is this happening in zsh?

[Damien Thébault]

On Wed, Mar 14, 2012 at 20:29, Heorhi Valakhanovich <valahanovich@tut.by> wrote:
> This happens in many command processors. I usually use quotes like
>
> fossil --ignore "*.class"
>
> This is not a solution but usual workaround.

Actually, I would say that it is a solution, and not a workaround.

Here is an example with the find command to explain my point of view.

Let's say you want to find files in this tree:

./file1.class
./folder1/file2.class
./folder1/file2.txt
./folder2/file3.class
./folder2/file3.txt

Let see in bash:

 $ find -name *.class
./file1.class
 $ find -name *.txt
./folder2/file3.txt
./folder1/file2.txt

In zsh:
% find -name *.class
./file1.class
% find -name *.txt
zsh: no matches found: *.txt

We can see that in bash, the first command and the second command are
not doing the same thing:
"find -name *.class" is expanded to [find] [-name] [file1.class]
"find -name *.txt" is not expanted and gives [find] [-name] [*.txt]

In zsh, both lines are processed the same way:
"find -name *.class" is expanded to [find] [-name] [file1.class]
"find -name *.txt" does not match anything and returns an error.

Obviously, only the second command in bash is giving the expected
result (find all files with a given extension), in zsh you don't get
any result and the first command is not giving the expected result in
both shells.

To avoid erroneous results like the first command, the wildcard must
be escaped so that it is always sent without modification to the find
command, like this:
 $ find -name "*.class"
./file1.class
./folder2/file3.class
./folder1/file2.class

or
 $ find -name \*.class
./file1.class
./folder2/file3.class
./folder1/file2.class

Escaping the pattern ensures that the command will receive the
expected pattern, you get the following in both bash and zsh:
"find -name \*.class" is expanded to [find] [-name] [*.class]

Not escaping the pattern is a bad habit that will give unexpected
results once in a while (like the example above), so I would say that
zsh's default behavior is good because it makes people understand how
it works and avoid those mistakes.

As it was said before, it's possible to activate the broken bash
behavior in zsh, but I don't think that it's a good solution.

Regards,
-- 
Damien Thebault

Re: Why is this happening in zsh?

[Nomen Nescio]

Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:

> On Wed, 14 Mar 2012 19:59:02 +0100 (CET)
> Anonymous <remailer@foo.asia-king.co.uk> wrote:
> > fossil --ignore *.class
> > zsh: no matches found *.class
> 
>   setopt nonomatch
> 
> fixes this.
> 
> If you are generally speaking expecting bash-like behaviour you might
> want to read the zshoptions manual page and note in particular options
> that are marked <S> (on in sh emulation) or <Z> (on by default in zsh
> but not necessarily emulations of other shells.

Guys: thanks very much indeed for the explanations, solutions and insights.
I have no illusions, bash and much of gnu software does things that aren't
consistent etc. I am not expecting zsh to work like bash either, if I wanted
that I would just use bash! I'm not very good with UNIX and I often miss
simple things. I do appreciate zsh works in a more uniform way. I knew there
was something about globbing but I couldn't get around it for some rsync
commands and now this. Now I think I understand a bit more. Thanks to
everyone who's answered!

Re: Why is this happening in zsh?

[Kyle Partridge]

So I alias these type of commands to use `noglob`. Does this solution make sense?

Ex:
	alias find="noglob find"

Re: Why is this happening in zsh?

[Christoph (Stucki) von Stuckrad]

On Thu, 15 Mar 2012, Kyle Partridge wrote:

> So I alias these type of commands to use `noglob`.
> Does this solution make sense?
> 
> Ex:
> 	alias find="noglob find"

This depends on what you really want to do and whether you alias
such command for a spcific case (good) or generally (bad).

Personally I prefer zsh's 'calling a missing * expansion an error',
because I normally tell the shell exactly what to do:

- eighter I write a simple * and 'globbing nothing' then IS an error
- or I use quoting, so I KNOW that the program called, will get the '*'

On the command line I mostly quote stars like: find ... -name \*foo\*
By doing this I keep the possibillity to do both in one comand,
like:

find some/tree/*/branches -name leaf\* -print

And the errormessage of the zsh keeps me from accidentally working
with real '*' in filenames or empty parameters, which can have VERY
strange results in daily work as a sysadmin :-)

Stucki


-- 
Christoph von Stuckrad      * * |nickname |Mail <stucki@mi.fu-berlin.de> \
Freie Universitaet Berlin   |/_*|'stucki' |Tel(Mo.,Mi.):+49 30 838-75 459|
Mathematik & Informatik EDV |\ *|if online|  (Di,Do,Fr):+49 30 77 39 6600|
Takustr. 9 / 14195 Berlin   * * |on IRCnet|Fax(home):   +49 30 77 39 6601/

Re: Why is this happening in zsh?

[Benjamin R. Haskell]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 855 bytes --]

On Thu, 15 Mar 2012, Kyle Partridge wrote:

> So I alias these type of commands to use `noglob`. Does this solution make sense?
>
> Ex:
> 	alias find="noglob find"

Usually, yes.  `find` is a bit different (for me at least), since I 
often want to do things like:

find ~gems/*3.2.0*(/) -exec grep -l some_method '{}' \;

(Not the best example, but the point is that I often glob to get the 
list of directories, and don't want to have to do it using `find` 
predicates.)

I've been using this function that PWS gave me¹:

alias find='noglob find'
'find'() {
 	integer i=${argv[(i)-*]}
 	command find ${~argv[1,i-1]} "${(@)argv[i,-1]}"
}

The alias turns on `noglob`, but then the function manually globs 
every argument prior to the first one that starts with a dash.

-- 
Best,
Ben

¹: zsh-users 15446 : http://www.zsh.org/mla/users/2010/msg00745.html