* Re: whence question [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 0 siblings, 1 reply; 26+ messages in thread From: Daniel Shahaf @ 2017-01-14 4:40 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users 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'». ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 4:40 ` whence question Daniel Shahaf @ 2017-01-14 4:57 ` Ray Andrews 2017-01-14 18:32 ` Ray Andrews 0 siblings, 1 reply; 26+ messages in thread From: Ray Andrews @ 2017-01-14 4:57 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 4:57 ` Ray Andrews @ 2017-01-14 18:32 ` Ray Andrews 2017-01-14 18:55 ` Bart Schaefer 0 siblings, 1 reply; 26+ messages in thread From: Ray Andrews @ 2017-01-14 18:32 UTC (permalink / raw) To: zsh-users 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`|| | |...|| | |}|| | ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 18:32 ` Ray Andrews @ 2017-01-14 18:55 ` Bart Schaefer 2017-01-14 19:51 ` Ray Andrews 0 siblings, 1 reply; 26+ messages in thread From: Bart Schaefer @ 2017-01-14 18:55 UTC (permalink / raw) To: zsh-users [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=( ${~@} ) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 18:55 ` Bart Schaefer @ 2017-01-14 19:51 ` Ray Andrews 2017-01-14 20:56 ` Daniel Shahaf 0 siblings, 1 reply; 26+ messages in thread From: Ray Andrews @ 2017-01-14 19:51 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 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:43 ` Bart Schaefer 0 siblings, 2 replies; 26+ messages in thread From: Daniel Shahaf @ 2017-01-14 20:56 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 20:56 ` Daniel Shahaf @ 2017-01-14 21:26 ` Ray Andrews 2017-01-14 21:53 ` Daniel Shahaf 2017-01-14 21:43 ` Bart Schaefer 1 sibling, 1 reply; 26+ messages in thread From: Ray Andrews @ 2017-01-14 21:26 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 21:26 ` Ray Andrews @ 2017-01-14 21:53 ` Daniel Shahaf 2017-01-15 19:53 ` Ray Andrews 0 siblings, 1 reply; 26+ messages in thread From: Daniel Shahaf @ 2017-01-14 21:53 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 21:53 ` Daniel Shahaf @ 2017-01-15 19:53 ` Ray Andrews 0 siblings, 0 replies; 26+ messages in thread From: Ray Andrews @ 2017-01-15 19:53 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 20:56 ` Daniel Shahaf 2017-01-14 21:26 ` Ray Andrews @ 2017-01-14 21:43 ` Bart Schaefer 2017-01-14 21:55 ` Bart Schaefer 1 sibling, 1 reply; 26+ messages in thread From: Bart Schaefer @ 2017-01-14 21:43 UTC (permalink / raw) To: zsh-users [-- 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 21:43 ` Bart Schaefer @ 2017-01-14 21:55 ` Bart Schaefer 2017-01-15 20:06 ` Ray Andrews 0 siblings, 1 reply; 26+ messages in thread From: Bart Schaefer @ 2017-01-14 21:55 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 21:55 ` Bart Schaefer @ 2017-01-15 20:06 ` Ray Andrews 0 siblings, 0 replies; 26+ messages in thread From: Ray Andrews @ 2017-01-15 20:06 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* whence question @ 2017-01-14 4:13 Ray Andrews 2017-01-14 5:11 ` Bart Schaefer 0 siblings, 1 reply; 26+ messages in thread From: Ray Andrews @ 2017-01-14 4:13 UTC (permalink / raw) To: Zsh Users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 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> 0 siblings, 2 replies; 26+ messages in thread From: Bart Schaefer @ 2017-01-14 5:11 UTC (permalink / raw) To: Zsh Users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 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> 1 sibling, 0 replies; 26+ messages in thread From: Ray Andrews @ 2017-01-14 6:09 UTC (permalink / raw) To: zsh-users 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. > ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <7b890e89-d01b-ab5c-32bf-b75bfa8d945c__41234.9168131643$1484374276$gmane$org@eastlink.ca>]
* Re: whence question [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:46 ` Jens Elkner 0 siblings, 2 replies; 26+ messages in thread From: Daniel Shahaf @ 2017-01-14 6:48 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users 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. ;-)] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 6:48 ` Daniel Shahaf @ 2017-01-14 16:36 ` Ray Andrews 2017-01-14 17:11 ` Bart Schaefer 2017-01-14 17:46 ` Jens Elkner 1 sibling, 1 reply; 26+ messages in thread From: Ray Andrews @ 2017-01-14 16:36 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 16:36 ` Ray Andrews @ 2017-01-14 17:11 ` Bart Schaefer 2017-01-14 19:13 ` Ray Andrews 0 siblings, 1 reply; 26+ messages in thread From: Bart Schaefer @ 2017-01-14 17:11 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 17:11 ` Bart Schaefer @ 2017-01-14 19:13 ` Ray Andrews 0 siblings, 0 replies; 26+ messages in thread From: Ray Andrews @ 2017-01-14 19:13 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 6:48 ` Daniel Shahaf 2017-01-14 16:36 ` Ray Andrews @ 2017-01-14 17:46 ` Jens Elkner 2017-01-14 17:59 ` Bart Schaefer 2017-01-14 19:08 ` Nikolay Aleksandrovich Pavlov (ZyX) 1 sibling, 2 replies; 26+ messages in thread From: Jens Elkner @ 2017-01-14 17:46 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 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) 1 sibling, 1 reply; 26+ messages in thread From: Bart Schaefer @ 2017-01-14 17:59 UTC (permalink / raw) To: Jens Elkner; +Cc: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 17:59 ` Bart Schaefer @ 2017-01-14 18:23 ` Jens Elkner 0 siblings, 0 replies; 26+ messages in thread From: Jens Elkner @ 2017-01-14 18:23 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 17:46 ` Jens Elkner 2017-01-14 17:59 ` Bart Schaefer @ 2017-01-14 19:08 ` Nikolay Aleksandrovich Pavlov (ZyX) 2017-01-14 20:13 ` Daniel Shahaf 1 sibling, 1 reply; 26+ messages in thread From: Nikolay Aleksandrovich Pavlov (ZyX) @ 2017-01-14 19:08 UTC (permalink / raw) To: Jens Elkner, zsh-users 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 19:08 ` Nikolay Aleksandrovich Pavlov (ZyX) @ 2017-01-14 20:13 ` Daniel Shahaf 2017-01-14 21:04 ` Bart Schaefer [not found] ` <4cca17742cded21984e6092622265ab9@cmgw03.eastlink.ca> 0 siblings, 2 replies; 26+ messages in thread From: Daniel Shahaf @ 2017-01-14 20:13 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: whence question 2017-01-14 20:13 ` Daniel Shahaf @ 2017-01-14 21:04 ` Bart Schaefer [not found] ` <4cca17742cded21984e6092622265ab9@cmgw03.eastlink.ca> 1 sibling, 0 replies; 26+ messages in thread From: Bart Schaefer @ 2017-01-14 21:04 UTC (permalink / raw) To: zsh-users [-- 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <4cca17742cded21984e6092622265ab9@cmgw03.eastlink.ca>]
* Re: whence question [not found] ` <4cca17742cded21984e6092622265ab9@cmgw03.eastlink.ca> @ 2017-01-14 21:44 ` Ray Andrews 0 siblings, 0 replies; 26+ messages in thread From: Ray Andrews @ 2017-01-14 21:44 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2017-01-15 20:06 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <652bcc3f-7365-2e52-d39c-8576278606bc__74.9235078275845$1484367323$gmane$org@eastlink.ca> 2017-01-14 4:40 ` whence question 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 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) 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
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).