Re: whence question

Re: whence question

[Daniel Shahaf]

Ray Andrews wrote on Fri, Jan 13, 2017 at 20:13:49 -0800:
> I'd expect the 'm' and 'a' switches to do their duty even if there is a
> local file.

That's expected when you have setopt nonomatch in your config.

The alternative is to leave the option at its default setting and use
«alias whence='noglob whence'».

Re: whence question

[Ray Andrews]

On 13/01/17 08:40 PM, Daniel Shahaf wrote:
> Ray Andrews wrote on Fri, Jan 13, 2017 at 20:13:49 -0800:
>> I'd expect the 'm' and 'a' switches to do their duty even if there is a
>> local file.
> That's expected when you have setopt nonomatch in your config.
>
> The alternative is to leave the option at its default setting and use
> «alias whence='noglob whence'».
>
So I do.  I can't remember what breaks when that's off, I'd better read 
up on it.

Thanks Daniel.

Re: whence question

[Ray Andrews]

On 13/01/17 08:57 PM, Ray Andrews wrote:
>
>
This seems to work and it uses my old friend 'noglob'. 'i' being my tell 
me absolutely everything hyper-whence:

|$ i grub-r* ||
||
||Local file:||
||-rw-r--r-- 1 root root 0 Jan 13 20:37 grub-r||
||grub-r: empty||
||
||Local file:||
||-rw-r--r-- 1 root root 0 Jan 13 20:52 grub-rr||
||grub-rr: empty||
||
||(1)TYPE: grub-r is an alias for echo this is a phony alias:||
||
||(2)TYPE: grub-r is a shell function:||
||
||(3)TYPE: grub-reboot is /usr/sbin/grub-reboot:||
||
||(4)TYPE: grub-render-label is /usr/bin/grub-render-label:||
|

--------------------------------------

But it's a nuisance:


|alias i='noglob _i'|||
|||function _i ()|||
|||{|||
||

|...
|

|# Because I need expanded arguments for the listing of the local files:||
|

|local _args=`eval echo $@`||
||_args=( ${(z)_args} )|

|for ((i = 1; i <= ${#_args}; i++)); do||
||    if [ -e ${_args[i]} ]; then||
||      infomsg "\nLocal file:"; ls -l ${_args[i]} | grep --color=auto 
-w $1||
||      file ${_args[i]} | grep --color=auto -w $1||
||    fi||
||done||
|

|...||
||# But from now on, 'whence -ma' receives the glob raw and behaves as 
expected:|

|local find_count=`whence -ma "$@" | wc -l`||
|

|...||
|

|}||
|

Re: whence question

[Bart Schaefer]

[What is up with all the ||...|| stuff?  Makes this really hard to read.]

On Sat, 14 Jan 2017, Ray Andrews wrote:

> On 13/01/17 08:57 PM, Ray Andrews wrote:
>
> |local _args=`eval echo $@`||
> | |_args=( ${(z)_args} )|

??  Why in the world are you using eval and (z) there?  The semantics of
(z) are likely to do something unexpected at some point (and Daniel will
note that if $1 starts with a hyphen, "echo" will treat it as an option
and do something else confusing).

  local _args=( ${~@} )

Re: whence question

[Ray Andrews]

On 14/01/17 10:55 AM, Bart Schaefer wrote:
>
>    local _args=( ${~@} )
>
>
Well nuts.  I use what seems to work and if there's a better way that I 
don't know about, then I don't know about it until I know about it.  I 
thought I learned that whenever 'nogob' was in effect that 'eval' was 
the only way to crack open a glob!  I've always hated it, so the above 
seems a huge improvement unless there's any gotchas with it.  So hard to 
really understand these myriads of syntactic tricks.   I'm still most of 
the time trying things by trial and error and saved snips of things that 
seemed to work elsewhere.  Real mastery is still some time off.  What 
would be useful is a sort of 'walk through' of some constructions so 
that the parse becomes human understandable.  Above I'd read: the local 
variable '_args' will be created as an array (split on God know what) 
set equal to the contents of the argument string (modified by the tilde 
in some way that I've never seen), the argument string being enclosed in 
'${}' because it is being modified ... so I almost read that one.

Re: whence question

[Daniel Shahaf]

Ray Andrews wrote on Sat, Jan 14, 2017 at 11:51:08 -0800:
> On 14/01/17 10:55 AM, Bart Schaefer wrote:
> >
> >   local _args=( ${~@} )
> >
> >
> [...] I almost read that one.

What you wrote is:

|local _args=`eval echo $@`||
||_args=( ${(z)_args} )|

Your input here was the positional arguments ($@), which are a list of
words parsed from the command line.

The input to eval is an unparsed command line string.  Therefore,
passing $@ to eval is a type mismatch.  It will cause filenames with
spaces to be split.  The way to interpolate variables into eval's
arguments is with (q), e.g., the following are equivalent:
.
     echo $foo
     eval echo ${(q)foo}

Next, using 'echo' will not safely round-trip arbitrary values;
filenames with spaces or backslashes would be mangled by it (even
without 'eval').

There are other problems here (splitting on spaces is the least of your
concerns with that 'eval'; it inteprets data as code), but circling back
to Bart's solution, what it does right is that it uses the correct data
types and applies the correct transformation.  That's because «${~@}»
happens to be a transformation that takes a "$@", interprets every word
in it as a glob, and returns a list of words.  (Without the round
parentheses, it'd return something else.)  It's documented in "Parameter
expansion" in zshexpn(1); grep for GLOB_SUBST.

Note also that the round parentheses are required, to declare an array
rather than a single string.

Cheers,

Daniel

Re: whence question

[Ray Andrews]

On 14/01/17 12:56 PM, Daniel Shahaf wrote:

Well you certainly trashed that.  But I never liked it anyway and I'm 
grateful for Bart's improvement.

Re: whence question

[Daniel Shahaf]

Ray Andrews wrote on Sat, Jan 14, 2017 at 13:26:07 -0800:
> On 14/01/17 12:56 PM, Daniel Shahaf wrote:
> 
> Well you certainly trashed that.

http://producingoss.com/en/you-are-what-you-write.html#rudeness

    Technical criticism, even when direct and unpadded, is not rude.
    Indeed, it can be a form of flattery: the critic is saying, by
    implication, that the target is worth taking seriously, and is worth
    spending some time on. That is, the more viable it would have been
    to simply ignore someone's post, the more of a compliment it becomes
    to take the time to criticize it (unless the critique descends into
    an ad hominem attack or some other form of obvious rudeness, of
    course). 

tl;dr: Reviewing your code is not a personal attack.  Quite the
opposite.

Cheers,

Daniel

Re: whence question

[Ray Andrews]

On 14/01/17 01:53 PM, Daniel Shahaf wrote:
> Ray Andrews wrote on Sat, Jan 14, 2017 at 13:26:07 -0800:
>> On 14/01/17 12:56 PM, Daniel Shahaf wrote:
>>
>> Well you certainly trashed that.
> http://producingoss.com/en/you-are-what-you-write.html#rudeness
>
>      Technical criticism, even when direct and unpadded, is not rude.

Of course not sensei, the trashing was most appropriate and most 
educational and most welcome.  Please accept my apologies if it sounded 
otherwise.  I welcome all correction and am flattered that you take the 
time.  There are so many gotchas in zsh --and I guess all shells -- that 
something might seem to work but still be littered with defects and I am 
grateful to have them pointed out. As I mentioned, I still do many 
things because I found them on Google and they seem to sorta work, but 
without any real understanding of what I'm doing, rather like reading 
from a tourist's phrase book.  Nope, like learning to speak Finnish, 
this ain't easy but I'll get there thanks largely to your good self.

Re: whence question

[Bart Schaefer]

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

On Sat, 14 Jan 2017, Daniel Shahaf wrote:

> «${~@}» happens to be a transformation that takes a "$@", interprets
> every word in it as a glob, and returns a list of words.  (Without the
> round parentheses, it'd return something else.)

Although strictly accurate, that's making it seem more mysterious than
it is.  It still returns the same glob results, and in the absence of
the assignment it would be the same list of words, but in an assignment
without the parentheses it would create a string by joining the words
together.

Re: whence question

[Bart Schaefer]

On Sat, 14 Jan 2017, Bart Schaefer wrote:

> On Sat, 14 Jan 2017, Daniel Shahaf wrote:
>
> Although strictly accurate, that's making it seem more mysterious than
> it is.  It still returns the same glob results [but]
> without the parentheses it would create a string by joining the words

Er, sorry, not quite right.  NO_GLOB_ASSIGN kicks in and overrides the
activation of GLOB_SUBST, so it does not return the glob results, just
the original strings.

Re: whence question

[Ray Andrews]

On 14/01/17 01:55 PM, Bart Schaefer wrote:

>
Oy vey. Ah, to have it all made understandable:


|nobareglobqual off||
||nocaseglob            off||
||cshnullglob           off||
||extendedglob          on||
||noglob                off||
||noglobalexport        off||
||noglobalrcs           off||
||globassign            off||
||globcomplete          off||
||globdots              on||
||globstarshort         off||
||globsubst             off||
||kshglob               off||
||nullglob              off||
||numericglobsort       off||
||shglob                off||
|

... some human-readable way of understanding what all of those really 
do, how they interact, and what one might actually want to use and why 
:(  I dare not touch it.  "The ordinary human's guide to configuring zsh 
(here's what you really want)"  10 to 50 pages.

whence question

[Ray Andrews]

Is this to be expected:


    $ whence -ma grub-r*
    /usr/sbin/grub-reboot
    /usr/bin/grub-render-label

    $ touch grub-r

    $ whence -ma grub-r*

    $ rm grub-r

    $ whence -ma grub-r*
    /usr/sbin/grub-reboot
    /usr/bin/grub-render-label


I'd expect the 'm' and 'a' switches to do their duty even if there is a 
local file.

Re: whence question

[Bart Schaefer]

On Fri, 13 Jan 2017, Ray Andrews wrote:

> Is this to be expected:
>
>    $ touch grub-r
>
>    $ whence -ma grub-r*
>

To expound a little on Daniel's answer, touching the file has made
"grub-r*" into a pattern that generates a file name, so instead of looking
for all commands matching the pattern you're looking for all commands
matching the name of the file -- of which there are none.

Re: whence question

[Ray Andrews]

On 13/01/17 09:11 PM, Bart Schaefer wrote:
> On Fri, 13 Jan 2017, Ray Andrews wrote:
>
>> Is this to be expected:
>>
>>     $ touch grub-r
>>
>>     $ whence -ma grub-r*
>>
> To expound a little on Daniel's answer, touching the file has made
> "grub-r*" into a pattern that generates a file name, so instead of looking
> for all commands matching the pattern you're looking for all commands
> matching the name of the file -- of which there are none.
I roughly understand that.  I know that if a glob has  no match it's 
passed verbatim so whence sees what it's supposed to see, but the fact 
that there is a match fouls that up.  It's a bit of a bother but 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, 
OTOH I can also speculate that whence might have this noglob built into 
it automatically whenever the 'm' is used so that there is no conflict 
-- but that might not be possible without the alias.  Certainly what 
happens is a bit of a gotcha, the incidental local match surely should 
not matter.  Shouldn't 'm' have complete control of globing, since 
that's what it's for?  Dunno, could/should whence be an alias by 
default?  or, since whence is a builtin, might it be possible to prevent 
the globing in the first place?  I understand that that wouldn't be 
possible with an external command but since it's in the family a bit of 
hokey pokey might be possible.  Sorta whence prepending 'noglob' to 
itself automatically.  Or maybe that's a really dumb idea.
>

Re: whence question

[Daniel Shahaf]

Ray Andrews wrote on Fri, Jan 13, 2017 at 22:09:54 -0800:
> On 13/01/17 09:11 PM, Bart Schaefer wrote:
> >To expound a little on Daniel's answer, [...]

Thanks, Bart.

> 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.

The most ${adjective} exception to the rule is the '[[' reserved word;
but note that its older variant, '[', abides by the rule.

Cheers,

Daniel
[sorry for that botched interpolation in the last paragraph; I had
nonomatch enabled in my compose window's parameter interpolation code
while I was writing this email. ;-)]

Re: whence question

[Ray Andrews]

On 13/01/17 10:48 PM, Daniel Shahaf wrote:
>
> 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'll take a closer look at those options, I'm always terrified that if I 
play with them I'll set a landmine what will blow up on me latter and 
I'll forget what it is that I changed or why things are broken.   Gotta 
make sure that nullglob and nonomatch don't trip over each other.  But 
first experiments:



> $ unsetopt nullglob; unsetopt nonomatch; whence -ma grub-r*
> $ unsetopt nullglob; setopt nonomatch; whence -ma grub-r*
> $ setopt nullglob; setopt nonomatch; whence -ma grub-r*
> $ setopt nullglob; unsetopt nonomatch; whence -ma grub-r*

Does that contradict? Nuthin' works.
>> [...] 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,

> 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.
Well, consistency trumps convenience.  Still I'd argue that my original 
example really is a gotcha, it's not something that would ever (?) be 
anticipated.  Just being devil's advocate here of course but in this 
case does not the 'm' switch in effect 'state' an exception?  That is, 
is it not an explicit request to change the rules vis a vis globing?  
Without 'm' I have no expectation that whence has any special power vis 
a vis globing (globbing?) but with 'm' I expect that it does.  Can we 
have intuitive behaviour and consistency if it was a stated principal 
that 'm' (and any other such devices) are immune to the artifact of the 
local match which is in no way a 'natural' target for whence anyway?  
IOW 'whence -ma grub-r*' should never be anything other than a search 
for natural whence targets and the local match could be seen as an 
error. Delicate tho, maybe not.

Re: whence question

[Bart Schaefer]

On Sat, 14 Jan 2017, Ray Andrews wrote:

> > $ unsetopt nullglob; unsetopt nonomatch; whence -ma grub-r*
> > $ unsetopt nullglob; setopt nonomatch; whence -ma grub-r*
> > $ setopt nullglob; setopt nonomatch; whence -ma grub-r*
> > $ setopt nullglob; unsetopt nonomatch; whence -ma grub-r*
>
> Does that contradict? Nuthin' works.

The options you're changing only matter when globbing FAILS.  If the
local file matching grub-r* exists, then globbing SUCCEEDS, and your
option changes mean nothing in context.

Try adding "unsetopt glob" to the mix (though you'd never want that in
regular usage).

> Just being devil's advocate here of course but in this case does not the
> 'm' switch in effect 'state' an exception?  That is, is it not an
> explicit request to change the rules vis a vis globing?

No, it isn't, because globbing is done by the shell long before it tries
to execute the "whence" (or any other) command, so at the time globbing
is done "-m" is just another syntactic word with no special meaning.

I'm pretty sure you and I have had this conversation before.  This isn't
like the old DOS shell where the arguments get passed verbatim and it is
up to the command to invoke the standard pattern matcher.  The order of
operations is different.

Re: whence question

[Ray Andrews]

On 14/01/17 09:11 AM, Bart Schaefer wrote:
> The options you're changing only matter when globbing FAILS. If the
> local file matching grub-r* exists, then globbing SUCCEEDS, and your
> option changes mean nothing in context.

Tx.
>
> Just being devil's advocate here of course but in this case does not the
> 'm' switch in effect 'state' an exception?  That is, is it not an
> explicit request to change the rules vis a vis globing?
> No, it isn't, because globbing is done by the shell long before it tries
> to execute the "whence" (or any other) command, so at the time globbing
> is done "-m" is just another syntactic word with no special meaning.

Yeah, I understand the order of processing (at least that detail), so my 
idea of special treatment for 'm' would indeed be an exception and could 
be ruled out for that reason alone.  I understand that it's no small 
thing to suggest it even if it were possible and maybe it simply isn't 
possible anyway.  Still, you hafta admit my first example has to be seen 
as a defect because 'whence -ma' has no reason to care about local 
files; globing in that situation is a different animal since whence has 
different targets.  IOW 'whence -ma' only does what it is expected to do 
when normal globing fails.   But perhaps this is so long established 
that the safe thing to do is to use Daniel's alias.  I'll make no 
further noise about it since I have a solution anyway and it's something 
I'm used to using.

Besides, it works fine when the glob is quoted and the docs say to quote 
when using 'm' and that's normal hygiene anyway ... so what am I 
bitching about ;-)  I'm being overly theoretical and wasting people's time.

Re: whence question

[Jens Elkner]

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,
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

Re: whence question

[Bart Schaefer]

On Sat, 14 Jan 2017, Jens Elkner wrote:

> 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.:
>
> Would be nice, if zsh could do the same (and enhance compatibility) ...

Zsh has had this for many years, except you suffix the pattern rather
than prefix it and there's no extra "~":

    for F in *.c(N) ; do ls $F ; done

Zsh can't readily adopt ksh's exact syntax here because ~(N)*.c is taken
to be a pattern grouping, e.g. ~(N|M)*.c would match home directories
for user names beginning with N or M and ending in .c.

Re: whence question

[Jens Elkner]

On Sat, Jan 14, 2017 at 09:59:05AM -0800, Bart Schaefer wrote:
> On Sat, 14 Jan 2017, Jens Elkner wrote:
> 
> > 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.:
> >
> > Would be nice, if zsh could do the same (and enhance compatibility) ...
> 
> Zsh has had this for many years, except you suffix the pattern rather
> than prefix it and there's no extra "~":
> 
>     for F in *.c(N) ; do ls $F ; done

Ah ok - good to know, thanx.
  
> Zsh can't readily adopt ksh's exact syntax here because ~(N)*.c is taken
> to be a pattern grouping, e.g. ~(N|M)*.c would match home directories
> for user names beginning with N or M and ending in .c.

Well, it is a special case, which needs some snooping, but does not
really collide with your example: as soon as something different than
'N' appears inside the parens, it can be handled as usual, otherwise
add the corresponding flag to the pattern (or wherever it is needed in
the state machine). If one really wants to have something from the
user[s] N* only, one can/should simply omit the parens - IMHO no big deal.

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

Re: whence question

[Nikolay Aleksandrovich Pavlov (ZyX)]

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

Re: whence question

[Daniel Shahaf]

Nikolay Aleksandrovich Pavlov (ZyX) wrote on Sat, Jan 14, 2017 at 22:08:44 +0300:
> \*  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.

Semantically, the glob «*.foo» and the literal filename «'*.foo'» would
be different types, if the shell language were strongly typed.  The
former would be a function that returns a list of words and the
latter would be (is) a word.

You could in principle define a pattern matching flavour where the
regexp /αλφα/ matches the plaintext «alfa», and then — let's assume for
the moment that all your filenames are ASCII — the commands
.
    % ls αλφα
    % ls alfa
.
would very clearly be different: one of them has a glob argument and one
of them has a literal string argument.

Now, the shell language is _not_ strongly typed, but nonetheless, when
people write «*.foo» intending a pattern that expands to one or more
filenames, it usually doesn't make sense to just use the pattern
instead — not any more than it would be logical for
.
    % echo αλφα > list-of-important-files.txt
.
to dump the Greek into the .txt file, in the example where all filenames
were ASCII.

Cheers,

Daniel

Re: whence question

[Bart Schaefer]

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

On Sat, 14 Jan 2017, Nikolay Aleksandrovich Pavlov (ZyX) wrote:

> (actually [nomatch] 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).

This is in part relatively new behavior, see users/22338 (which I expected
to spawn some discussion but has gone unanswered).

> 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.

CSH_NULL_GLOB is quite useful if you are using several globs and don't
know whether only some of them might match.  Generates the error only
if none of the globs match, silently removes the subset that don't if
some of them do.

On Sat, 14 Jan 2017, Daniel Shahaf wrote:

> Semantically, the glob «*.foo» and the literal filename «'*.foo'» would
> be different types, if the shell language were strongly typed.

That's stretching things a bit.  For that to be true, every command would
have to declare the types of its arguments.

In this particular case the shell does have "strong enough" data typing:
quoted strings vs. not-quoted strings.  The former are never wordlists
(unless a well-typed expansion inside them is a wordlist) and the latter
are always wordlists (which might result in only one word).

You just have to explicitly declare the type by providing the quotes.

Re: whence question

[Ray Andrews]

On 14/01/17 01:04 PM, Bart Schaefer wrote:
>
> You just have to explicitly declare the type by providing the quotes.

So it's really a question of literacy:  Understanding the point of the 'm' switch the literate coder knows to quote automatically.  And as Nikolay Aleksandrovich pointed out, receiving a bit of discipline when one has not quoted is quite appropriate.  Most educational! Thanks all.