Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: whence question

14.01.2017, 20:47, "Jens Elkner" <jel+zsh@xxxxxxxxxxxxxxxxxxx>:
> On Sat, Jan 14, 2017 at 06:48:07AM +0000, Daniel Shahaf wrote:
>>  Ray Andrews wrote on Fri, Jan 13, 2017 at 22:09:54 -0800:
> ...
>>  > I know that if a glob has no match it's passed verbatim so whence
>>  > sees what it's supposed to see,
>>  That's only true when 'setopt nonomatch' is in effect, which is not the
>>  default. By default, globs that have no match are considered errors.
>>  The NULL_GLOB option selects a third mode. See:
>>      % cd $(mktemp -d)
>>      % echo foo*
>>      zsh: no matches found: foo*
>>      % (setopt nullglob; echo foo*) | nl -ba
>>      % (setopt nonomatch; echo foo*)
>>      foo*
>>      %
>>  > [...] I can see that without 'noglob' the shell's zeal for expanding
>>  > globs is in more or less direct conflict with the intention of the 'm'
>>  > switch which supposes that whence will handle globing itself. I can
>>  > also see that that might not be fixable even in theory for reasons of
>>  > consistency,
>>  Right: while there are several ways to make a shell builtin command see
>>  globs in arguments, the default behaviour of existing (released)
>>  commands can't be changed for compatibility reasons.
>>  Also, the existing design has merits: *every* external and builtin
>>  command parses "words with globbing metacharacters" the same way.
>>  «echo *foo» and «whence *foo» and «bar *foo» are all subject to the
>>  same rules. The rules are consistent for everybody. That's a feature.
> I also prefer the default (i.e. use literal if no match), because it is
> IMHO safer than just dropping it (and opt. emit an err msg). However,

It is safer then just dropping because many commands behave differently when they have zero file arguments. But I cannot say so about emitting error message: zsh does not *drop* and optionally emit an error message. Zsh emits error message *without executing the command* (actually it aborts execution: check difference between `xxx-nonexistent-command-xxx ; echo abc` and `echo xxx-nonexistent-file-xxx* ; echo abc`: first will show “command not found” message *and* `abc`, second will just show an error). In some cases this is desired cource of action\*, and there is also a reason why errorring is safer: you complained that if there is a file `whence` behave differently. I bet you would not complain here if you had `NOMATCH` enabled: simply because when you most of time are *forced* to escape a glob you *will always* escape a glob when you mean to pass it literally. So problem will not occur in first place and you don’t get unexpected results simply because you tried to run command in a wrong directory.

I have `NOMATCH` enabled also because I like Python “explicit is better then implicit” principle: if I mean glob expansion I write glob expression and zsh either performs glob expansion or errors out. If I mean literal glob character I have it escaped and globbing is not performed because I explicitly escaped it, not because zsh found no matches. And additional reasoning: command will run slightly faster if you escape glob characters because zsh will not first try to expand it (not that I or most of other zsh users really care about this fact: normally you will not notice additional delay).

\*  E.g. when you issue `vim *.foo` you most likely do not want to open `*.foo` file if you happen to spell glob wrong or `tar cf foo.tar *.foo` will create empty archive if glob is spelled wrong and it received unexistent file as an argument.

> especially in 'for' like statements, dropping it silently makes sense
> (is expected). To accomplish this in an easy way, ksh93 allows one to
> prefix the pattern with '~(N)' , e.g.:
> for F in ~(N)*.c ; do ls $F ; done
> or
> for F in ~(N)*.c ; do ls ${F%.c}/*.o ; done
> Would be nice, if zsh could do the same (and enhance compatibility) ...
> Have fun,
> jel.
> --
> Otto-von-Guericke University http://www.cs.uni-magdeburg.de/
> Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2
> 39106 Magdeburg, Germany Tel: +49 391 67 52768

Messages sorted by: Reverse Date, Date, Thread, Author