PATH_DIRS

PATH_DIRS

[Ray Andrews]

Noticing how PATH_DIRS behaves in a way parallel or complementary to 
PATH, I wonder if whence might be tweaked to search for scripts on 
PATH_DIRS sorta exactlyas it searches for binarieson PATH.  It would 
round the command out by enabling it to find any sort of executable 
whatever-- alias, function, binary, builtin or (now) script.

Re: PATH_DIRS

[Bart Schaefer]

On Thu, Aug 10, 2017 at 2:46 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> Noticing how PATH_DIRS behaves in a way parallel or complementary to PATH, I
> wonder if whence might be tweaked to search for scripts on PATH_DIRS

PATH_DIRS is a setopt, it *uses* $PATH.  It's not a parameter
providing alternate directories.

Anyway, it already does search like that.  You just have to chmod +x
the script files (and add a #! line if they aren't zsh scripts).

What it WON'T do is source scripts it finds that way into the current
shell.  It'll always fork a subshell for them.  Too many opportunities
for mayhem if the user hasn't explicitly asked (via the "." command)
to have his current shell altered (potentially) by the script.

Re: PATH_DIRS

[Ray Andrews]

On 10/08/17 03:19 PM, Bart Schaefer wrote:
> PATH_DIRS is a setopt, it *uses* $PATH. It's not a parameter
> providing alternate directories.

I would have been up the garden path there, cuz I:

$ PATH_DIR=/aWorking/Zsh/System
$ echo $PATH_DIR
/aWorking/Zsh/System

... which seemed to do just as I thought I was expecting,  however now I 
see that since that directory is on my PATH anyway, it worked but only 
(it seems) by virtue of  it working all the time anyway and I just 
didn't realize that, and  I was making an unrelated and useless variable 
:( Now I see that I completely missed the real use of that setopt.   
Thanks, God only knows how many knots I'd have tied myself into there.
>
> Anyway, it already does search like that.  You just have to chmod +x
> the script files (and add a #! line if they aren't zsh scripts).
However, scripts are run even if chmod -x, tho whence will only find 
them if '+x'.   Am I somehow missing the boat there?


>
> What it WON'T do is source scripts it finds that way into the current
> shell.  It'll always fork a subshell for them.  Too many opportunities
> for mayhem if the user hasn't explicitly asked (via the "." command)
> to have his current shell altered (potentially) by the script.
>
Yeah, I don't begrudge the dot, good to know what one is doing. Still, I 
find myself wanting whence to find anything that is executable on the 
PATH.  If I can:

/aWorking/Zsh/System $ ls -l somescript
-rw-r--r-- 1 root root 24 Aug 10 21:55 somescript     <<< not marked 
executable.

/aWorking/Zsh/System $ cat somescript

echo this is somescript

/aMisc $ . somescript
this is somescript

... so it will be run if it's a script on my PATH, even if not '+x' then 
it seems intuitive that whence would also be able to find it.

Re: PATH_DIRS

[Ray Andrews]

On 10/08/17 10:07 PM, Ray Andrews wrote:
> ... so it will be run if it's a script on my PATH, even if not '+x' 
> then it seems intuitive that whence would also be able to find it.
>
>
Ah ... 'whence -m' not 'whence -ma' and it seems to be true one-stop 
shopping, all files are found, mind, that would be text files that 
aren't scripts, too, but 'file' shows the difference based on the 
hashbang, so I can use that to filter out non scripts since I always 
have a hashbang in any script.  Not to be unclear about what I want to 
do, but it is a caution that I can:

$ . pea_soup_recipe

... and it tries to execute that if I was so unorganized as to have that 
file on my path somewhere.  As Bart said, one can see the protection of 
requiring '+x', but that does not seem to be the case.

Re: PATH_DIRS

[Bart Schaefer]

On Thu, Aug 10, 2017 at 10:07 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 10/08/17 03:19 PM, Bart Schaefer wrote:
>>
>> Anyway, it already does search like that.  You just have to chmod +x
>> the script files (and add a #! line if they aren't zsh scripts).
>
> However, scripts are run even if chmod -x, tho whence will only find them if
> '+x'.   Am I somehow missing the boat there?

You're confusing scripts read with the "." (or "source") commands with
programs that are found by path search where the program happens to be
a script.

That is, with or without PATH_DIRS set, if you have a script named
"myscript" in a directory in $PATH and you chmod +x it, then you can
run it by just typing "myscript" in command position, without
prefixing it by ". ".  With PATH_DIRS set, you can run ". myscript"
with or without that executable permission on the file (it need only
be readable).

When I said:

>> What it WON'T do is source scripts it finds that way into the current
>> shell.

By "that way" I meant "path search where the program happens to be a
script."  Obviously (I hope), the "." command always does source
things into the current shell.

> I find myself wanting whence to find anything that is executable on the PATH.

Some people use "chmod +x" on scripts exactly for this reason, whether
they intend to always run them via the "." command or not.

Re: PATH_DIRS

[Ray Andrews]

On 13/08/17 08:20 PM, Bart Schaefer wrote:
> With PATH_DIRS set, you can run ". myscript"
> with or without that executable permission on the file (it need only be readable).

Then how do I get these results?:

/aWorking/Zsh/Source 3$ unsetopt pathdirs        # This directory is not 
on the path

/aWorking/Zsh/Source 3$ chmod -x ../System/somescript      # Referring 
here to somescript which is on the path.

/aWorking/Zsh/Source 3$ somescript
zsh: permission denied: somescript              # As expected

/aWorking/Zsh/Source 3$ . somescript
this is somescript                                          # As expected

/aWorking/Zsh/Source 3$ chmod +x ../System/somescript

/aWorking/Zsh/Source 3$ somescript        # As expected
this is somescript

/aWorking/Zsh/Source 3$ . somescript
this is somescript                                        # As expected

/aWorking/Zsh/Source 3$ setopt pathdirs    # But the results are unchanged:

/aWorking/Zsh/Source 3$ chmod -x ../System/somescript

/aWorking/Zsh/Source 3$ somescript
zsh: permission denied: somescript

/aWorking/Zsh/Source 3$ . somescript
this is somescript

/aWorking/Zsh/Source 3$ chmod +x ../System/somescript

/aWorking/Zsh/Source 3$ somescript
this is somescript

/aWorking/Zsh/Source 3$ . somescript
this is somescript

... what am I doing wrong?

Re: PATH_DIRS

[Jim]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

Hi Ray,(Sorry if you get this twice, forgot to send to list the first time.)

On Mon, Aug 14, 2017 at 10:53 PM, Ray Andrews <rayandrews@eastlink.ca>
wrote:

> On 13/08/17 08:20 PM, Bart Schaefer wrote:
>
>> With PATH_DIRS set, you can run ". myscript"
>> with or without that executable permission on the file (it need only be
>> readable).
>>
>
> Then how do I get these results?:
>
> /aWorking/Zsh/Source 3$ unsetopt pathdirs        # This directory is not
> on the path
>
> /aWorking/Zsh/Source 3$ chmod -x ../System/somescript      # Referring
> here to somescript which is on the path.
>
>
> snip ...

>
> ... what am I doing wrong


Nothing, as far as I can tell.  I believe it is your point of view what
PATH_DIRS is doing.  As long as "somescript" is in your PATH,
I don't believe PATH_DIRS is doing much if anything.

Try the following to understand what PATH_DIRS can do:

  mkdir ../System/Subdir
  mv ../System/somescript ../System/Subdir
  unsetopt pathdirs
  . Subdir/somescript       # script should not run
  setopt pathdirs
  . Subdir/somescript       # should see output from script

I believe from reading the man page, this is what PATH_DIRS is
intended to do.  As Bart said, it *uses* PATH. If you +x somescript
you can just type:

  Subdir/somescript

At least this is how I interpreted what PATH_DIRS, as defined in the man
page, does.  "Perform a path search even on command names with
slashes in them."  Maybe it should say, "In addition to the normal path
search, preform a path search on command names with slashes in them."
Maybe I'm missing some other case use.

Hope this helps.

Jim

Re: PATH_DIRS

[Bart Schaefer]

On Tue, Aug 15, 2017 at 9:50 AM, Jim <linux.tech.guy@gmail.com> wrote:
>
> Nothing, as far as I can tell.  I believe it is your point of view what
> PATH_DIRS is doing.  As long as "somescript" is in your PATH,
> I don't believe PATH_DIRS is doing much if anything.

Right, I got a bit confused about what Ray was asking (and also was
thinking of "source" which always looks first in the current
directory).

Sorry about that.

Re: PATH_DIRS

[Ray Andrews]

On 15/08/17 10:32 AM, Bart Schaefer wrote:
> On Tue, Aug 15, 2017 at 9:50 AM, Jim <linux.tech.guy@gmail.com> wrote:
>> Nothing, as far as I can tell.  I believe it is your point of view what
>> PATH_DIRS is doing.  As long as "somescript" is in your PATH,
>> I don't believe PATH_DIRS is doing much if anything.
> Right, I got a bit confused about what Ray was asking
Sometimes even the question contains errors, so thereyago  we can't 
expect mindreading.

At the end of the day all I want is for whence to show me sourcable 
scripts as well as +x scripts.  Since sourcable scripts are found and 
run according to PATH etiquette  (although the current dir is also 
always searched and we have the PATH_DIR option as well) I want whence 
to inform me what command will be run if I type it and press enter:

  6 /aWorking/Zsh/Source 2$ whence somescript
[nothing]

6 /aWorking/Zsh/Source 2$ . somescript
this is somescript on the path

... In fact somescript is runable and is found on the path.  Now, if it 
is the case that I want to run it under a subshell and I 'chmod +x 
somescript', then of course it shows up in a whence search, BUT I might 
very well simply want to source it and in either case I think whence 
should find it for me.  That is, if the shell will search for it and run 
it (even as a sourced script) then whence should show it to me IMHO 
whether I choose to source it or execute it ... which it sorta does if I 
use '-m'.

And there is this bafflement:

/aWorking/Zsh/Source/Wk $ whence -mav more
more is /aWorking/Zsh/System/more                            # 'more is 
a 'chmod +x' script on the path.
more is /bin/more
# output as expected '-a' shows all files found,  -' m' does the pattern 
search giving my script and the binary.  But now:

/aWorking/Zsh/Source $ chmod -x aWorking/Zsh/System/somescript

/aWorking/Zsh/Source $ whence more
/bin/more
# Fine, unless I " $ . more " in which case I get something else and the 
previous command gave the script the prior listing, suggesting it has 
prior execution, no?

/aWorking/Zsh/Source/Wk $ whence -mv more
more is /aWorking/Zsh/System/more
#  OK,  my script would be the first thing executed *IF* I sourced it 
but not if I executed it in which case I get the binary.

3 /aWorking/Zsh/Source/Wk 5$ whence -mav more
more is /bin/more
# Where did my script go?  '-a' seems to cancel '-m' here, I expect both 
'-m' and '-a' to add output, not subtract from it.  Basically, it seems 
intuitive to me that if I make a script I think of it as the same 
animal, whether I source it or execute it.  Dunno, maybe this is really 
correct and if I understood it better it would seem intuitive but at the 
moment the fact that sourced scripts are searched for on the path seems 
to me to give them the same 'rank' as any other runnable thingy and I 
expect whence to find them as such. I'm not thinking of 'whence -m' as a 
sort of 'find', I want to see what is going to execute.  If  the 'more' 
script is good enough for 'whence -m' then 'whence -am' should show it 
too.  No?  But it's complicated, maybe what I think I want would break 
some other logic.  As it is, to get one-stop shopping, my wrapper shows 
me this:

6 /aWorking/Zsh/Source 2$ i more

Searching the path for text files or scripts that are not '+x':

LISTING: -rw-r--r-- 1 18 2017-08-16/08:16:07 /aWorking/Zsh/System/more
CONTENT: PLAIN   text/plain; charset=us-ascii:

Aliases, functions, builtins, executable scripts/text or binaries: Found 
1 matches:

(1)TYPE: more is /bin/more:
LISTING: -rwxr-xr-x 1 39752 2017-03-22/02:43:33 /bin/more*
CONTENT: EXECUTABLE LIBRARY application/x-sharedlib; charset=binary:

... so I know what's actually going on, but it seems to me that whence 
should give me one-stop shopping too.

Re: PATH_DIRS

[Jim]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

Hi Ray,

On Wed, Aug 16, 2017 at 11:22 AM, Ray Andrews <rayandrews@eastlink.ca>
wrote:

> On 15/08/17 10:32 AM, Bart Schaefer wrote:
>
>> On Tue, Aug 15, 2017 at 9:50 AM, Jim <linux.tech.guy@gmail.com> wrote:
>>
>>> Nothing, as far as I can tell.  I believe it is your point of view what
>>> PATH_DIRS is doing.  As long as "somescript" is in your PATH,
>>> I don't believe PATH_DIRS is doing much if anything.
>>>
>> Right, I got a bit confused about what Ray was asking
>>
> Sometimes even the question contains errors, so thereyago  we can't expect
> mindreading.
>
> At the end of the day all I want is for whence to show me sourcable
> scripts as well as +x scripts.  Since sourcable scripts are found and run
> according to PATH etiquette  (although the current dir is also always
> searched and we have the PATH_DIR option as well) I want whence to inform
> me what command will be run if I type it and press enter:
>
> snip ...

I am having a problem with the above statement, in particular the part
"although the current dir is also always searched".  To source a script
you can use one of two builtins, "." or "source". According to the man
page, for the "." builtin:

"Files in the current directory are not read unless `.' appears somewhere
in $path."

For the "source" builtin:

"Same as `.', except that the current directory is always searched and is
always searched first, before directories in $path."

As all examples in this email thread were using the "." builtin the above
statement didn't make sense to me. To be honest, until I reread the man
page, I always thought that both builtins were doing the same identical
thing. Learned "my" something new for today.

Hopefully I did not misreading what you were trying to state.

Jim

Re: PATH_DIRS

[Ray Andrews]

On 20/08/17 03:59 AM, Jim wrote:
>
> "Same as `.', except that the current directory is always searched and is
> always searched first, before directories in $path."

Yeah, that's one of those things that's a gotcha or a feature depending 
on your level of advancement.  It's so easy to forget the difference and 
then it bites you, esp. in cases like mine where the current directory 
is on my path, so they are functionally the same here even tho they are 
not the same.  Come to think of it, that might be another thing that 
whence should control.

Re: PATH_DIRS

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

On 15/08/17 07:30 AM, Jim wrote:
> Hi Ray,

> Try the following to understand what PATH_DIRS can do:
>
>   mkdir ../System/Subdir
>   mv ../System/somescript ../System/Subdir
>   unsetopt pathdirs
>   . Subdir/somescript       # script should not run
>   setopt pathdirs
>   . Subdir/somescript       # should see output from script
>
> I believe from reading the man page, this is what PATH_DIRS is
> intended to do.  As Bart said, it *uses* PATH. If you +x somescript
> you can just type:
>
>   Subdir/somescript
>
> At least this is how I interpreted what PATH_DIRS, as defined in the man
> page, does.  "Perform a path search even on command names with
> slashes in them."  Maybe it should say, "In addition to the normal path
> search, preform a path search on command names with slashes in them."
> Maybe I'm missing some other case use.
>
> Hope this helps.
>
> Jim


Hugely, thanks Jim.   The doc frankly baffled me, now I get it, it adds 
subdirectories of the path to the (effective) path.   Why not just say 
that?  Seemed to be talking about slashes as parts of filenames or some 
such voodoo.  Now Bart's "uses PATH" is understandable.  Darkest just 
before dawn!