From: Stephane Chazelas <stephane_chazelas@yahoo.fr>
To: Anonymous <remailer@foo.asia-king.co.uk>
Cc: zsh-users@zsh.org
Subject: Re: Why is this happening in zsh?
Date: Wed, 14 Mar 2012 19:42:52 +0000 [thread overview]
Message-ID: <20120314194252.GD6799@yahoo.fr> (raw)
In-Reply-To: <3d1c765788f2c6b89b58beae6b318b54@foo.asia-king.co.uk>
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
next prev parent reply other threads:[~2012-03-14 19:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-14 18:59 Anonymous
2012-03-14 19:29 ` Heorhi Valakhanovich
2012-03-14 23:19 ` Damien Thébault
2012-03-14 19:42 ` Stephane Chazelas [this message]
2012-03-14 19:49 ` Peter Stephenson
2012-03-15 10:13 ` Nomen Nescio
2012-03-15 18:00 ` Kyle Partridge
2012-03-16 0:11 ` Christoph (Stucki) von Stuckrad
2012-03-16 3:28 ` Benjamin R. Haskell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120314194252.GD6799@yahoo.fr \
--to=stephane_chazelas@yahoo.fr \
--cc=remailer@foo.asia-king.co.uk \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).