permission denied

permission denied

[Ray Andrews]

     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.

Re: permission denied

[Ray Andrews]

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.



>

Re: permission denied

[Bart Schaefer]

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.

Re: permission denied

[Ray Andrews]

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.

Re: permission denied

[Peter Stephenson]

> 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

Re: permission denied

[Ray Andrews]

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.


>

Re: permission denied

[Bart Schaefer]

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.

Re: permission denied

[Ray Andrews]

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.

Re: permission denied

[Roman Perepelitsa]

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.

Re: permission denied

[Bart Schaefer]

Try it with

% print -rl "Hello World"

Re: permission denied

[Ray Andrews]

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.

Re: permission denied

[Roman Perepelitsa]

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.

Re: permission denied

[Ray Andrews]

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.





>
>
>
>>
>

Re: permission denied

[Ray Andrews]

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.



>

Re: permission denied

[Bart Schaefer]

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.

Re: permission denied

[Ray Andrews]

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.

Re: permission denied

[Bart Schaefer]

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

Re: permission denied

[Ray Andrews]

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.

Re: permission denied

[Roman Perepelitsa]

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

permission denied

[Ray Andrews]

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?