zsh-users
 help / color / mirror / code / Atom feed
From: "Nikolay Aleksandrovich Pavlov (ZyX)" <kp-pav@yandex.ru>
To: Jens Elkner <jel+zsh@cs.uni-magdeburg.de>,
	"zsh-users@zsh.org" <zsh-users@zsh.org>
Subject: Re: whence question
Date: Sat, 14 Jan 2017 22:08:44 +0300	[thread overview]
Message-ID: <6237271484420924@web15h.yandex.ru> (raw)
In-Reply-To: <20170114174622.GA12641@trex.cs.ovgu.de>



14.01.2017, 20:47, "Jens Elkner" <jel+zsh@cs.uni-magdeburg.de>:
> 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

  parent reply	other threads:[~2017-01-14 19:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-14  4:13 Ray Andrews
2017-01-14  5:11 ` Bart Schaefer
2017-01-14  6:09   ` Ray Andrews
     [not found]   ` <7b890e89-d01b-ab5c-32bf-b75bfa8d945c__41234.9168131643$1484374276$gmane$org@eastlink.ca>
2017-01-14  6:48     ` Daniel Shahaf
2017-01-14 16:36       ` Ray Andrews
2017-01-14 17:11         ` Bart Schaefer
2017-01-14 19:13           ` Ray Andrews
2017-01-14 17:46       ` Jens Elkner
2017-01-14 17:59         ` Bart Schaefer
2017-01-14 18:23           ` Jens Elkner
2017-01-14 19:08         ` Nikolay Aleksandrovich Pavlov (ZyX) [this message]
2017-01-14 20:13           ` Daniel Shahaf
2017-01-14 21:04             ` Bart Schaefer
     [not found]             ` <4cca17742cded21984e6092622265ab9@cmgw03.eastlink.ca>
2017-01-14 21:44               ` Ray Andrews
     [not found] <652bcc3f-7365-2e52-d39c-8576278606bc__74.9235078275845$1484367323$gmane$org@eastlink.ca>
2017-01-14  4:40 ` Daniel Shahaf
2017-01-14  4:57   ` Ray Andrews
2017-01-14 18:32     ` Ray Andrews
2017-01-14 18:55       ` Bart Schaefer
2017-01-14 19:51         ` Ray Andrews
2017-01-14 20:56           ` Daniel Shahaf
2017-01-14 21:26             ` Ray Andrews
2017-01-14 21:53               ` Daniel Shahaf
2017-01-15 19:53                 ` Ray Andrews
2017-01-14 21:43             ` Bart Schaefer
2017-01-14 21:55               ` Bart Schaefer
2017-01-15 20:06                 ` Ray Andrews

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=6237271484420924@web15h.yandex.ru \
    --to=kp-pav@yandex.ru \
    --cc=jel+zsh@cs.uni-magdeburg.de \
    --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).