* permission denied @ 2023-04-17 18:34 Ray Andrews 2023-04-17 19:07 ` Roman Perepelitsa 0 siblings, 1 reply; 20+ messages in thread From: Ray Andrews @ 2023-04-17 18:34 UTC (permalink / raw) To: Zsh Users So, now having my 'chain' variable and experimenting with using it as a command, I run into this problem with any of my functions, like 'l' here: % chain=( ls ); $chain ... OK as expected % chain=( l ); $chain zsh: permission denied: l % chain=( l ); eval $chain ... works fine. It seems strange that a perfectly usable function throws 'permission denied' used that way. IIRC there are times when that message is misleading, it's not really a permissions issue but something else. I vaguely recall crashing into this before but I can't remember what the real reason was. And why does 'eval' fix it? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-17 18:34 permission denied Ray Andrews @ 2023-04-17 19:07 ` Roman Perepelitsa 2023-04-17 20:41 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Roman Perepelitsa @ 2023-04-17 19:07 UTC (permalink / raw) To: Ray Andrews; +Cc: Zsh Users > On Mon, Apr 17, 2023 at 8:46 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > So, now having my 'chain' variable and experimenting with using it as a > command, I run into this problem with any of my functions, like 'l' here: > > % chain=( ls ); $chain > > ... OK as expected > > % chain=( l ); $chain > > zsh: permission denied: l > > % chain=( l ); eval $chain > > ... works fine. > > It seems strange that a perfectly usable function throws 'permission > denied' used that way. IIRC there are times when that message is > misleading, it's not really a permissions issue but something else. I > vaguely recall crashing into this before but I can't remember what the > real reason was. And why does 'eval' fix it? Run `which l` and have your question answered. Roman. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-17 19:07 ` Roman Perepelitsa @ 2023-04-17 20:41 ` Ray Andrews 2023-04-17 21:52 ` Bart Schaefer 0 siblings, 1 reply; 20+ messages in thread From: Ray Andrews @ 2023-04-17 20:41 UTC (permalink / raw) To: zsh-users On 2023-04-17 12:07, Roman Perepelitsa wrote: > > Run `which l` and have your question answered. Ah. It's an alias. Nuts, I should have thought of that. Unaliased functions are ok. Still I don't understand why it won't run, shouldn't the alias be ok? I've basically never run a command via a variable this way before now so I'm not hardened as to what to expect. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-17 20:41 ` Ray Andrews @ 2023-04-17 21:52 ` Bart Schaefer 2023-04-17 22:44 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2023-04-17 21:52 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Mon, Apr 17, 2023 at 1:42 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Ah. It's an alias. Still I don't understand why it won't run, shouldn't > the alias be ok? Aliases are replaced before variable substitutions occur (if that weren't true, you couldn't refer to a variable in an alias). ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-17 21:52 ` Bart Schaefer @ 2023-04-17 22:44 ` Ray Andrews 2023-04-18 2:41 ` Bart Schaefer 0 siblings, 1 reply; 20+ messages in thread From: Ray Andrews @ 2023-04-17 22:44 UTC (permalink / raw) To: zsh-users On 2023-04-17 14:52, Bart Schaefer wrote: > > Aliases are replaced before variable substitutions occur (if that > weren't true, you couldn't refer to a variable in an alias). > So, when $chain expands to 'l' it's too late for 'l' to undergo alias expansion? Gotta think about that, no doubt there's rigor in order of operations but it seems counter intuitive here. I'm expecting 'l' to be processed just as it would be if typed on the command line. Mind, that's what 'eval' does. Maybe if I thought about it a bit harder then I'd see it. Obviously very basic stuff, not open to critique, but I'm expecting 'outside in' parsing so that an alias inside a variable and a variable inside an alias would both be fully expanded. Still there could be very good reasons not to do that I suppose. Probably not worth worrying about. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-17 22:44 ` Ray Andrews @ 2023-04-18 2:41 ` Bart Schaefer 2023-04-18 3:35 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2023-04-18 2:41 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Mon, Apr 17, 2023 at 3:44 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > So, when $chain expands to 'l' it's too late for 'l' to undergo alias > expansion? Gotta think about that, no doubt there's rigor in order of > operations but it seems counter intuitive here. Think of aliases as preprocessor directives like #define in C, and you'll get there. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-18 2:41 ` Bart Schaefer @ 2023-04-18 3:35 ` Ray Andrews 2023-04-20 21:35 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Ray Andrews @ 2023-04-18 3:35 UTC (permalink / raw) To: zsh-users On 2023-04-17 19:41, Bart Schaefer wrote: > > Think of aliases as preprocessor directives like #define in C, and > you'll get there. I can almost smell that it's something best accepted as it is. BTW, I figured out the message. Seems in the unacceptability of the alias 'l', she keeps looking, and finds the file named 'l' on the path and, it being a source file (containing alias 'l' and the called function '_l') and not being executable, 'permission denied' is about the right thing to say about file 'l'. If not on the path, the message is 'command not found'. I had thought that 'permission denied' referred to the alias. Dunno, perhaps 'zsh: permission denied, file: ./l' might be friendlier, it would at least be clear what the shell is chewing on there. So at the end of it 'eval' is my friend in need. > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-18 3:35 ` Ray Andrews @ 2023-04-20 21:35 ` Ray Andrews 2023-04-20 21:47 ` Roman Perepelitsa 0 siblings, 1 reply; 20+ messages in thread From: Ray Andrews @ 2023-04-20 21:35 UTC (permalink / raw) To: zsh-users Bart: > > On 2023-04-17 19:41, Bart Schaefer wrote: >> >> Think of aliases as preprocessor directives like #define in C, and >> you'll get there. > > I can almost smell that it's something best accepted as it is. BTW, I > figured out the message. Seems in the unacceptability of the alias > 'l', she keeps looking, and finds the file named 'l' on the path and, > it being a source file (containing alias 'l' and the called function > '_l') and not being executable, 'permission denied' is about the right > thing to say about file 'l'. If not on the path, the message is > 'command not found'. I had thought that 'permission denied' referred > to the alias. Dunno, perhaps 'zsh: permission denied, file: ./l' > might be friendlier, it would at least be clear what the shell is > chewing on there. So at the end of it 'eval' is my friend in need. One last question: You did this: chain0=( ${(s:; :)${(z)1}} ) ... ignoring the semicolon stuff for now, since it's more a matter of principal than practice for me: chain0=( ${=1} ) ... that would seem the more 'normal' thing, but you've obviously used '(z)' pointedly. What's the difference here? The manual leaves me feeling rather vague. > > > >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-20 21:35 ` Ray Andrews @ 2023-04-20 21:47 ` Roman Perepelitsa 2023-04-20 22:09 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Roman Perepelitsa @ 2023-04-20 21:47 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Thu, Apr 20, 2023 at 11:36 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Bart: > > > > On 2023-04-17 19:41, Bart Schaefer wrote: > >> > >> Think of aliases as preprocessor directives like #define in C, and > >> you'll get there. > > > > I can almost smell that it's something best accepted as it is. BTW, I > > figured out the message. Seems in the unacceptability of the alias > > 'l', she keeps looking, and finds the file named 'l' on the path and, > > it being a source file (containing alias 'l' and the called function > > '_l') and not being executable, 'permission denied' is about the right > > thing to say about file 'l'. If not on the path, the message is > > 'command not found'. I had thought that 'permission denied' referred > > to the alias. Dunno, perhaps 'zsh: permission denied, file: ./l' > > might be friendlier, it would at least be clear what the shell is > > chewing on there. So at the end of it 'eval' is my friend in need. > > One last question: > > You did this: > > chain0=( ${(s:; :)${(z)1}} ) > > ... ignoring the semicolon stuff for now, since it's more a matter of > principal than practice for me: > > chain0=( ${=1} ) > > ... that would seem the more 'normal' thing, but you've obviously used > '(z)' pointedly. What's the difference here? The manual leaves me > feeling rather vague. You'll see the difference if you set `1='echo "hello world"'. Roman. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-20 21:47 ` Roman Perepelitsa @ 2023-04-20 22:09 ` Ray Andrews 2023-04-20 22:13 ` Bart Schaefer 2023-04-20 22:17 ` Roman Perepelitsa 0 siblings, 2 replies; 20+ messages in thread From: Ray Andrews @ 2023-04-20 22:09 UTC (permalink / raw) To: zsh-users On 2023-04-20 14:47, Roman Perepelitsa wrote: > You'll see the difference if you set `1='echo "hello world"'. I'm not seeing any change. Mind, '$1' will only be set internally by preexec() I'd never try to fool with it directly. 0 /aWorking/Zsh/Source/Wk 0 % echo "hello world" hello world 0 /aWorking/Zsh/Source/Wk 0 % $chain1 "hello world" 0 /aWorking/Zsh/Source/Wk 0 % zsh # Changed my .zshrc and reinstate the '(z)' form: 0 /aWorking/Zsh/Source/Wk 1 % echo "hello world" hello world 0 /aWorking/Zsh/Source/Wk 1 % $chain1 "hello world" ... The manual does mention something about quotes but I don't know what 'taking into account' is supposed to mean. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-20 22:09 ` Ray Andrews @ 2023-04-20 22:13 ` Bart Schaefer 2023-04-20 22:47 ` Ray Andrews 2023-04-20 22:17 ` Roman Perepelitsa 1 sibling, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2023-04-20 22:13 UTC (permalink / raw) To: Zsh Users Try it with % print -rl "Hello World" ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-20 22:13 ` Bart Schaefer @ 2023-04-20 22:47 ` Ray Andrews 2023-04-21 3:12 ` Bart Schaefer 0 siblings, 1 reply; 20+ messages in thread From: Ray Andrews @ 2023-04-20 22:47 UTC (permalink / raw) To: zsh-users On 2023-04-20 15:13, Bart Schaefer wrote: > Try it with > > % print -rl "Hello World" > Ah! '(z)' takes care not to split within quotes. Sheesh, why doesn't the manual just say that? 'taking into account' is a bit vague. I'm never sure about anything when it comes to splitting, but I'd have expected the '=' to do the 'normal' thing and '(z)' to do something 'specialized' in some way, but in this case it strikes me that '(z)' is doing the 'right' thing. Anyway '(z)' it must be! Tx. Roman: > I think this is the 3rd time I'm giving you this tip. Please remember it. I got as far as remembering that there was something I was supposed to remember. :-) Seriously, there are times when I might use some diagnostic or fix received here in a purely ad hoc way, that is, I just want to solve some problem right now and I don't retain any lessons cuz there's too much going on in my head. In a more relaxed situation the lesson itself is more important that the specific problem. Yes! Remember that what you see is sometimes not an accurate reflection of the genuine internal state of a variable, thus, if in doubt, use 'typeset -p'. It's one of those 'real world' skills that you never read in a book or article. Also, I take long breaks between coding frenzies, during which I often feel I've forgotten 99% of everything I ever knew. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-20 22:47 ` Ray Andrews @ 2023-04-21 3:12 ` Bart Schaefer 2023-04-21 13:33 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2023-04-21 3:12 UTC (permalink / raw) To: zsh-users On Thu, Apr 20, 2023 at 3:47 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Ah! '(z)' takes care not to split within quotes. Sheesh, why doesn't > the manual just say that? Because that's not all it does. The first part of the sentence -- "Split the result of the expansion into words using shell parsing" -- is the important bit. (The "i.e." in "i.e. taking" should probably be an "e.g." as it is only one example of what happens.) $=x only splits on spaces. (z) gives you a separate word for each shell token, so e.g. "<file" becomes the two words "<" and "file", and "echo foo;" becomes 3 words "echo", "foo", and ";", and so on. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-21 3:12 ` Bart Schaefer @ 2023-04-21 13:33 ` Ray Andrews 2023-04-21 14:12 ` Peter Stephenson 0 siblings, 1 reply; 20+ messages in thread From: Ray Andrews @ 2023-04-21 13:33 UTC (permalink / raw) To: zsh-users On 2023-04-20 20:12, Bart Schaefer wrote: > > Because that's not all it does. The first part of the sentence -- > "Split the result of the expansion into words using shell parsing" -- > is the important bit. (The "i.e." in "i.e. taking" should probably be > an "e.g." as it is only one example of what happens.) Yeah, it makes it look like that's the entire point. > $=x only splits on spaces. (z) gives you a separate word for each > shell token See, now that's entirely clear and instantly understandable. Especially by juxtaposing the two, one is left in no doubt. Formal knowledge becomes practical knowledge. > , so e.g. "<file" becomes the two words "<" and "file", and > "echo foo;" becomes 3 words "echo", "foo", and ";", and so on. But: "echo foo" remains one word because it's quoted! Yes? Anyway, as always a few simple examples make it understandable. BTW, this hardly matters in practice but: 4 /aWorking/Zsh/Source/Wk 0 % print -rl "Hello World" Hello World 4 /aWorking/Zsh/Source/Wk 0 % $chain1 "Hello World" ... can the quotes be omitted from the output? I tried: " chain0=( ${(Qz)1} ) " but then it broke into two words again. Not important but if it can be done I'll take it. > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-21 13:33 ` Ray Andrews @ 2023-04-21 14:12 ` Peter Stephenson 2023-04-21 14:42 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Peter Stephenson @ 2023-04-21 14:12 UTC (permalink / raw) To: zsh-users > On 21/04/2023 14:33 Ray Andrews <rayandrews@eastlink.ca> wrote: > BTW, this hardly matters in practice but: > > 4 /aWorking/Zsh/Source/Wk 0 % print -rl "Hello World" > Hello World > > 4 /aWorking/Zsh/Source/Wk 0 % $chain1 > "Hello World" > > ... can the quotes be omitted from the output? I tried: " chain0=( > ${(Qz)1} ) " but then it broke into two words again. Not important but > if it can be done I'll take it. Yes, you can do ${(Q)${(z)1}} which does the splitting, then removes the quotes (without any more splitting). The nested expansions are needed because otherwise the (Q) happens before the (z) (search the zshexpn manual page for "brain damage" for the ordering rules). pws ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-21 14:12 ` Peter Stephenson @ 2023-04-21 14:42 ` Ray Andrews 2023-04-21 21:58 ` Bart Schaefer 0 siblings, 1 reply; 20+ messages in thread From: Ray Andrews @ 2023-04-21 14:42 UTC (permalink / raw) To: zsh-users On 2023-04-21 07:12, Peter Stephenson wrote: > > Yes, you can do ${(Q)${(z)1}} which does the splitting, then removes the > quotes (without any more splitting). The nested expansions are needed > because otherwise the (Q) happens before the (z) (search the zshexpn > manual page for "brain damage" for the ordering rules). No chance! I'll preserve what neurons I still have and just take your word for it. I can't believe that mortals wrote those ordering rules, it's inhuman. Musta been Gods From Outer Space. Seriously tho, it's good to remember that by nesting things, one can enforce an order of processing. Thanks Peter. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-21 14:42 ` Ray Andrews @ 2023-04-21 21:58 ` Bart Schaefer 2023-04-22 0:56 ` Ray Andrews 0 siblings, 1 reply; 20+ messages in thread From: Bart Schaefer @ 2023-04-21 21:58 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Fri, Apr 21, 2023 at 7:42 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > On 2023-04-21 07:12, Peter Stephenson wrote: > > > > Yes, you can do ${(Q)${(z)1}} which does the splitting, then removes the > > quotes (without any more splitting). That's probably not what you actually want to do, though. When I gave you the (z) solution, there was no expectation that you'd directly execute $chain -- it's not going to do the right thing if it actually is a chain of two or more commands, or has redirections, or any other complexity; instead it will just run the first command with all the separators and subsequent tokens and commands as part of the argument list. In this circumstance using eval would be much closer to correct. But --- why are you even bothering to split it at all if the intention is to run it? I thought the point was to put it in the history or some other editable place as separate commands. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-21 21:58 ` Bart Schaefer @ 2023-04-22 0:56 ` Ray Andrews 0 siblings, 0 replies; 20+ messages in thread From: Ray Andrews @ 2023-04-22 0:56 UTC (permalink / raw) To: zsh-users On 2023-04-21 14:58, Bart Schaefer wrote: > > In this circumstance using eval would be much closer to correct. That's how my system currently works, and it works fine, but I'm tinkering with any possible improvements, namely being able to use $chain1 instead of history. > But > --- why are you even bothering to split it at all if the intention is > to run it? I thought the point was to put it in the history or some > other editable place as separate commands. Yeah, it's all just experimentation. Sometimes, indeed % chain1 ... cooks off and does something useful, other times 'eval' seems needed. I don't think I've ever explained it well, but the only purpose is to be able to tinker with one of my functions in two steps: 1) what do I want? 2) how do I get it? By writing and retrieving from history -- or a variable, I can do stage one tinkering very easily: 0 /aWorking/Zsh/Source/Wk 1 % l ,H h* # ',H' switch saves to history LISTING of "h*": All file types, INsensitive. Sorting upside down by: Mod. Time: 640 [2022-12-22--07:12] highlight.css 3307 [2023-01-19--16:17] h,1,light edits, old code removed 3279 [2023-01-19--17:41] h,2,got n_list working 3279 [2023-01-19--17:41] h Items found: 4 Total bytes in directory "/aWorking/Zsh/Source/Wk": 1.5M Total including subdirs: 25M ... press the up arrow (retrieve last command) and I get the 'real' command executed above: 0 /aWorking/Zsh/Source/Wk 1 % ls --time-style='+[%F--%H:%M]' --group-directories-first -AFrGgdt --color=always (#i)h* 2> /dev/null | sed -r "s/^(.{10} {1,3}[[:digit:]]{1,3} )/ /" | egrep -v '^total' | sed '/;34m\.\x1b\[0m\/$/d' | perl -pe "s|\] (.*?)(h)|\] \1^[[31;1m\2^[[0m|i" 640 [2022-12-22--07:12] highlight.css 3307 [2023-01-19--16:17] h,1,light edits, old code removed 3279 [2023-01-19--17:41] h,2,got n_list working 3279 [2023-01-19--17:41] h ... so if I want to tinker, I can edit the above 'real' command, and then, once I know what I want to change, I go to my own code, which constructs the above, and make it construct it with the desired modification. Two steps. So, in practice, I'll never need to worry about multi-command command lines. It's all a bit involved but as I do it now 'eval' is always used. If you ever have a morbid curiosity about what I've been doing all these years: https://github.com/RayAndrews56/zsh-wrappers ... I'd be most interested in a review! 'c' and 'h' really are genuinely useful. > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: permission denied 2023-04-20 22:09 ` Ray Andrews 2023-04-20 22:13 ` Bart Schaefer @ 2023-04-20 22:17 ` Roman Perepelitsa 1 sibling, 0 replies; 20+ messages in thread From: Roman Perepelitsa @ 2023-04-20 22:17 UTC (permalink / raw) To: Ray Andrews; +Cc: zsh-users On Fri, Apr 21, 2023 at 12:09 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > 0 /aWorking/Zsh/Source/Wk 0 % $chain1 Recall that you can use `typeset -p` to see the value of a parameter. I think this is the 3rd time I'm giving you this tip. Please remember it. Roman. ^ permalink raw reply [flat|nested] 20+ messages in thread
* permission denied @ 2020-12-21 23:01 Ray Andrews 0 siblings, 0 replies; 20+ messages in thread From: Ray Andrews @ 2020-12-21 23:01 UTC (permalink / raw) To: Zsh Users typeset -a files_list=( *(N) ) ... That used to work in a function I have to grab a directory listing. Now I get the permission denied msg. It's such terse code that you can't hope to google anything about it. Replacement code using 'ls' works fine. The above is the sort of thing that I don't even know where to look in the docs but I do know that it is proper zsh code. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2023-04-22 0:57 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-04-17 18:34 permission denied Ray Andrews 2023-04-17 19:07 ` Roman Perepelitsa 2023-04-17 20:41 ` Ray Andrews 2023-04-17 21:52 ` Bart Schaefer 2023-04-17 22:44 ` Ray Andrews 2023-04-18 2:41 ` Bart Schaefer 2023-04-18 3:35 ` Ray Andrews 2023-04-20 21:35 ` Ray Andrews 2023-04-20 21:47 ` Roman Perepelitsa 2023-04-20 22:09 ` Ray Andrews 2023-04-20 22:13 ` Bart Schaefer 2023-04-20 22:47 ` Ray Andrews 2023-04-21 3:12 ` Bart Schaefer 2023-04-21 13:33 ` Ray Andrews 2023-04-21 14:12 ` Peter Stephenson 2023-04-21 14:42 ` Ray Andrews 2023-04-21 21:58 ` Bart Schaefer 2023-04-22 0:56 ` Ray Andrews 2023-04-20 22:17 ` Roman Perepelitsa -- strict thread matches above, loose matches on Subject: below -- 2020-12-21 23:01 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).