* Why is this happening in zsh? @ 2012-03-14 18:59 Anonymous 2012-03-14 19:29 ` Heorhi Valakhanovich ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Anonymous @ 2012-03-14 18:59 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why is this happening in zsh? 2012-03-14 18:59 Why is this happening in zsh? Anonymous @ 2012-03-14 19:29 ` Heorhi Valakhanovich 2012-03-14 23:19 ` Damien Thébault 2012-03-14 19:42 ` Stephane Chazelas 2012-03-14 19:49 ` Peter Stephenson 2 siblings, 1 reply; 9+ messages in thread From: Heorhi Valakhanovich @ 2012-03-14 19:29 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why is this happening in zsh? 2012-03-14 19:29 ` Heorhi Valakhanovich @ 2012-03-14 23:19 ` Damien Thébault 0 siblings, 0 replies; 9+ messages in thread From: Damien Thébault @ 2012-03-14 23:19 UTC (permalink / raw) To: Heorhi Valakhanovich; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why is this happening in zsh? 2012-03-14 18:59 Why is this happening in zsh? Anonymous 2012-03-14 19:29 ` Heorhi Valakhanovich @ 2012-03-14 19:42 ` Stephane Chazelas 2012-03-14 19:49 ` Peter Stephenson 2 siblings, 0 replies; 9+ messages in thread From: Stephane Chazelas @ 2012-03-14 19:42 UTC (permalink / raw) To: Anonymous; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why is this happening in zsh? 2012-03-14 18:59 Why is this happening in zsh? Anonymous 2012-03-14 19:29 ` Heorhi Valakhanovich 2012-03-14 19:42 ` Stephane Chazelas @ 2012-03-14 19:49 ` Peter Stephenson 2012-03-15 10:13 ` Nomen Nescio 2 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 2012-03-14 19:49 UTC (permalink / raw) To: Anonymous; +Cc: zsh-users 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/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why is this happening in zsh? 2012-03-14 19:49 ` Peter Stephenson @ 2012-03-15 10:13 ` Nomen Nescio 2012-03-15 18:00 ` Kyle Partridge 0 siblings, 1 reply; 9+ messages in thread From: Nomen Nescio @ 2012-03-15 10:13 UTC (permalink / raw) To: zsh-users 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! ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why is this happening in zsh? 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 0 siblings, 2 replies; 9+ messages in thread From: Kyle Partridge @ 2012-03-15 18:00 UTC (permalink / raw) To: Nomen Nescio; +Cc: zsh-users So I alias these type of commands to use `noglob`. Does this solution make sense? Ex: alias find="noglob find" ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why is this happening in zsh? 2012-03-15 18:00 ` Kyle Partridge @ 2012-03-16 0:11 ` Christoph (Stucki) von Stuckrad 2012-03-16 3:28 ` Benjamin R. Haskell 1 sibling, 0 replies; 9+ messages in thread From: Christoph (Stucki) von Stuckrad @ 2012-03-16 0:11 UTC (permalink / raw) To: zsh-users 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/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Why is this happening in zsh? 2012-03-15 18:00 ` Kyle Partridge 2012-03-16 0:11 ` Christoph (Stucki) von Stuckrad @ 2012-03-16 3:28 ` Benjamin R. Haskell 1 sibling, 0 replies; 9+ messages in thread From: Benjamin R. Haskell @ 2012-03-16 3:28 UTC (permalink / raw) To: Kyle Partridge; +Cc: Nomen Nescio, zsh-users [-- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-03-16 3:35 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-14 18:59 Why is this happening in zsh? Anonymous 2012-03-14 19:29 ` Heorhi Valakhanovich 2012-03-14 23:19 ` Damien Thébault 2012-03-14 19:42 ` Stephane Chazelas 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
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).