[-- Attachment #1: Type: text/plain, Size: 2119 bytes --] Trying to get whence to be both case insensitive and accepting of patterns I noticed something interesting. The first item in my $PATH is the dot, I take this as not unusual because one might want to execute some command found in the current directory. Anyway: 0 /aWorking/Zsh/Source/Wk 1 $ whence -mavS "(#i)*rap" RAP is an alias for echo howdy _trap is an autoload shell function rap is a shell function from rap trap is a shell builtin bwrap is /usr/bin/bwrap select-default-iwrap is /usr/bin/select-default-iwrap ... I have a whole load of various absurdly named test files in the current directory but whence doesn't find them. However if I modify my PATH to make the dot expand to the ( do we say 'canonical' ? ) ... the actual name of the current directory: 0 /aWorking/Zsh/Source/Wk 1 $ vared PATH /aWorking/Zsh/Source/Wk:/aWorking/Zsh/System:/aWorking/Bin:/usr/local/bin:/usr/sbin:/usr/bin: ... everything is found: 0 /aWorking/Zsh/Source/Wk 1 $ whence -mavS "(#i)*rap" RAP is an alias for echo howdy _trap is an autoload shell function rap is a shell function from rap trap is a shell builtin RAP is /aWorking/Zsh/Source/Wk/RAP RAP is RAP RAp is /aWorking/Zsh/Source/Wk/RAp RAp is RAp RaP is /aWorking/Zsh/Source/Wk/RaP -> /aWorking/Zsh/Source/Wk/RAP RaP is RaP bwrap is /usr/bin/bwrap rAp is /aWorking/Zsh/Source/Wk/rAp rAp is rAp select-default-iwrap is /usr/bin/select-default-iwrap ... all my silly files show up, infact they show up twice. The eg: "RAP is RAP" doesn't seem to say very much when we already have: "RAP is /aWorking/Zsh/Source/Wk/RAP" We can even get three restatements: 2 /aWorking/Zsh/Source/Wk 0 $ /bin 2 /bin 0 $ whence -mavS "zsh" zsh is ./zsh zsh is /usr/bin/zsh zsh is zsh ... again the last line doesn't seem very useful. The first is of course true and the second line seems to highlight the fact that in Debian '/bin' is a link to '/usr/bin'. Thoughts? Can I have the full output while leaving the dot in my path? [-- Attachment #2: Type: text/html, Size: 2872 bytes --]
On Mon, Oct 31, 2022 at 2:31 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> We can even get three restatements:
>
>
> 2 /aWorking/Zsh/Source/Wk 0 $ /bin
>
> 2 /bin 0 $ whence -mavS "zsh"
>
> zsh is ./zsh
> zsh is /usr/bin/zsh
> zsh is zsh
Here's what I get with zsh 5.9:
% docker run -e TERM -it --rm zshusers/zsh:5.9 zsh
# cd /usr/bin
# PATH=.:$PATH whence -mavS zsh
zsh is ./zsh
zsh is /usr/bin/zsh
Does this look the way you want?
How do I get "zsh is zsh" in the output? Are you perchance on an old
version of zsh? Which one?
Roman.
On 2022-10-31 06:43, Roman Perepelitsa wrote: > > % docker run -e TERM -it --rm zshusers/zsh:5.9 zsh > # cd /usr/bin > # PATH=.:$PATH whence -mavS zsh > zsh is ./zsh > zsh is /usr/bin/zsh > > Does this look the way you want? Better sure, the redundant line isn't there. > > How do I get "zsh is zsh" in the output? Are you perchance on an old > version of zsh? Which one? 2 /usr/bin 1 $ zsh --version zsh 5.8 (x86_64-debian-linux-gnu) ... maybe time for an upgrade? Debian is always behind the times. > Roman. >
On Mon, Oct 31, 2022 at 3:06 PM Ray Andrews <rayandrews@eastlink.ca> wrote: >> > On 2022-10-31 06:43, Roman Perepelitsa wrote: > > > > % docker run -e TERM -it --rm zshusers/zsh:5.9 zsh > > # cd /usr/bin > > # PATH=.:$PATH whence -mavS zsh > > zsh is ./zsh > > zsh is /usr/bin/zsh > > > > Does this look the way you want? > > Better sure, the redundant line isn't there. Is there anything else in the output that you don't like? > > > > How do I get "zsh is zsh" in the output? Are you perchance on an old > > version of zsh? Which one? > 2 /usr/bin 1 $ zsh --version > > zsh 5.8 (x86_64-debian-linux-gnu) I get the same output with zsh 5.8 as with 5.9. It's the output I posted above. There must be something else in your setup that is required to get the line saying "zsh is zsh". Roman.
I get the same output with zsh 5.8 as with 5.9. It's the output I posted above. > There must be something else in your setup that is required to get the > line saying "zsh is zsh". Hmmm ... it's down to the dot it seems: ... With the expanded dot in my path: 2 /bin 0 $ whence -mavS "zsh" zsh is /usr/bin/zsh 2 /bin 0 $ zsh ... Restart puts the dot back in the path: 2 /bin 1 $ whence -mavS "zsh" zsh is ./zsh zsh is /usr/bin/zsh zsh is zsh > > Roman. >
On Mon, Oct 31, 2022 at 3:32 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> I get the same output with zsh 5.8 as with 5.9. It's the output I posted
> above.
> > There must be something else in your setup that is required to get the
> > line saying "zsh is zsh".
>
> Hmmm ... it's down to the dot it seems:
I did prepend dot to PATH. You can see the full listing of commands in
my first reply.
Roman.
On 2022-10-31 07:36, Roman Perepelitsa wrote:
> I did prepend dot to PATH. You can see the full listing of commands in
> my first reply.
Yeah I noticed but I think our situations are different. I'll bet you
can duplicate my output if you tinker with your path. Sheesh, what else
could it be? Anyway that's a small matter, what's bugging me is the way
whence doesn't show everything if the dot is not expanded. Right now
I'm doing this hack:
oldpath=$PATH
ppath=( $( realpath -s $path ) ) # realpath
needs spaces between dirs.
PATH=$( echo $ppath | sed -r "s/ /:/g" ) # put the
colons back
all_matches=( ${(f)"$( whence -mavS (#i)$1 )"} ) # fire up whence
PATH=$oldpath # restore PATH
... and I end up with 'everything' being found in the current
directory. Pretty horrible tho. Dunno, what could I have done to make
that necessary? Seems to me whence simply doesn't look for files in a
'dot' directory. Why else would expanding it change the output? How
could that be my breaking something? Mind, I can break anything.
On Mon, Oct 31, 2022 at 7:57 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Yeah I noticed but I think our situations are different. I'll bet you
> can duplicate my output if you tinker with your path. Sheesh, what else
> could it be?
It's the -m option. If you ask for a pattern match, "whence" rebuilds
the internal command hash table from the path and then does the
matching against that. However, "." is never used when loading the
hash table because it would become invalid as soon as you change
directories. If $PWD is actually in the path, then those commands DO
get put in the hash table, so whence reports them. This should
probably be clarified in the documentation -- whence never does
globbing on actual file names.
You don't see this as a persistent condition because you're running
"whence" in a subshell with $(...).
The "zsh is zsh" output means you have an empty path element, e.g. two
consecutive colons in $PATH or $PATH begins or ends with colon, and an
executable or link named "zsh" in the current directory.
On Mon, Oct 31, 2022 at 2:18 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> It's the -m option. If you ask for a pattern match, "whence" rebuilds
> the internal command hash table from the path and then does the
> matching against that. However, "." is never used when loading the
> hash table because it would become invalid as soon as you change
> directories.
There's one additional thing going on. When you use BOTH -a and -m,
then anything found in the hash table with -m is searched for AGAIN by
-a, using the name as found in the hash table rather than the pattern
supplied as the -m argument. This is why "zsh" shows up multiple
times but your garbled-name scripts do not.
On 2022-10-31 14:18, Bart Schaefer wrote: > On Mon, Oct 31, 2022 at 7:57 AM Ray Andrews <rayandrews@eastlink.ca> wrote: >> It's the -m option. If you ask for a pattern match, "whence" rebuilds >> the internal command hash table from the path and then does the >> matching against that. However, "." is never used when loading the >> hash table because it would become invalid as soon as you change >> directories. If $PWD is actually in the path, then those commands DO >> get put in the hash table, so whence reports them. That can be in there literally? I'll try that. But wouldn't the same reasoning apply as with dot? Anyway I get the point, you can't rehash at every directory change. > This should > probably be clarified in the documentation -- whence never does > globbing on actual file names. > > You don't see this as a persistent condition because you're running > "whence" in a subshell with $(...). > > The "zsh is zsh" output means you have an empty path element, e.g. two > consecutive colons in $PATH or $PATH begins or ends with colon, and an > executable or link named "zsh" in the current directory. > > 2 /aWorking/Zsh/Source/Wk 1 $ echo $PATH > /aWorking/Zsh/Source/Wk:/usr/local/bin:/usr/sbin:/usr/bin: > Thereyago, I'll kill that trailing colon. Still, it seems like something that should be ignored.
> >> If $PWD is actually in the path
>
> That can be in there literally?
No, that's not what I meant. $PWD was shorthand for "the expanded
name of the current directory" like you were generating with
$(realpath).
On Mon, Oct 31, 2022, at 6:59 PM, Ray Andrews wrote:
> On 2022-10-31 14:18, Bart Schaefer wrote:
>> The "zsh is zsh" output means you have an empty path element, e.g. two
>> consecutive colons in $PATH or $PATH begins or ends with colon, and an
>> executable or link named "zsh" in the current directory.
>>
>
>> 2 /aWorking/Zsh/Source/Wk 1 $ echo $PATH
>> /aWorking/Zsh/Source/Wk:/usr/local/bin:/usr/sbin:/usr/bin:
>>
> Thereyago, I'll kill that trailing colon. Still, it seems like
> something that should be ignored.
Why should whence ignore it? An empty PATH element actually means
something to PATH searches; it is not cosmetic.
--
vq
On 2022-10-31 16:03, Bart Schaefer wrote:
>>>> If $PWD is actually in the path
>> That can be in there literally?
> No, that's not what I meant. $PWD was shorthand for "the expanded
> name of the current directory" like you were generating with
> $(realpath).
>
I'm just experimenting with that now, but it seems to work ... but only
once per restart of the shell, just as I really should expect. Back to
the dot. So it has to be dynamic.
On 2022-10-31 16:14, Lawrence Velázquez wrote:
> Why should whence ignore it? An empty PATH element actually means
> something to PATH searches; it is not cosmetic.
>
What use would that be?
On Mon, Oct 31, 2022 at 4:17 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2022-10-31 16:03, Bart Schaefer wrote:
> >>>> If $PWD is actually in the path
> >> That can be in there literally?
> > No, that's not what I meant.
> >
> I'm just experimenting with that now, but it seems to work ... but only
> once per restart of the shell, just as I really should expect. Back to
> the dot. So it has to be dynamic.
If you don't mind the overhead, you can muck around with $path in your
chpwd function to force the full current directory to always be there.
On Mon, Oct 31, 2022 at 4:21 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2022-10-31 16:14, Lawrence Velázquez wrote:
> > Why should whence ignore it? An empty PATH element actually means
> > something to PATH searches; it is not cosmetic.
> >
> What use would that be?
It's an archaic synonym for ".", included for backward compatibility.
See POSIX spec.
On 2022-10-31 16:38, Bart Schaefer wrote: > It's an archaic synonym for ".", included for backward compatibility. > See POSIX spec. Not me! Nothing I need worry about. Strange tho, if you want dot on your path then say so. I'm glad it's archaic, that's sloppy magic. BTW as to '-a' and '-m' they sure don't get along. I have a few examples where they seem to try to cancel each other. Seems to me that -m is an expansion of -a: show all matches AND extend that to wildcards. So -m subsumes -a. > If you don't mind the overhead, you can muck around with $path in your > chpwd function to force the full current directory to always be there. > Na I'm good. It's just that I want full path disclosure in my function cuz I need the full path later on. My crude search (not prettied up yet) seems about right: Searching for aliases, reserved words and autoloads. Then searching the path for regular functions, builtins (no path), and executable scripts or binary commands ... Found 9 match(es): ACTIVE: RAP is an alias for echo howdy RAP is /aWorking/Zsh/Source/Wk/RAP ACTIVE: RAp is /aWorking/Zsh/Source/Wk/RAp ACTIVE: RaP is /aWorking/Zsh/Source/Wk/RaP ACTIVE: bwrap is /usr/bin/bwrap ACTIVE: rAp is /aWorking/Zsh/Source/Wk/rAp ACTIVE: rap is an alias for echo pard rap is a shell function from rap ACTIVE: select-default-iwrap is /usr/bin/select-default-iwrap ACTIVE: _trap is an autoload shell function ACTIVE: trap is a shell builtin ... it's all there and where we have a name conflict I know which twin is active. BTW, you know what would be sweet, is if: "rap is a shell function from rap" ... if there was the option of having that displayed with full path. Throw in a case-insensitive option and all the work I've done in this function will be mostly obviated.
On Mon, Oct 31, 2022 at 5:03 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > > as to '-a' and '-m' they sure don't get along. I have a few examples > where they seem to try to cancel each other. Seems to me that -m is an > expansion of -a No. -m means to find all the names (in any hash table) that match a pattern. -a means to show all the occurrences in $path of each name (either literally without -m, or found in the command hash table by -m). -m happens first, and then -a searches the path. > BTW, you know what would be sweet, is if: "rap is a shell function from > rap" ... if there was the option of having that displayed with full > path. Whether a full path appears there depends on how the function was defined. The only way you get the output with "... from ..." but without the full path is if you source the function from a file in the current directory (e.g., "source rap"). Even autoloading the function with "fpath=(.); autoload rap; rap" gets you the full path.
On 2022-10-31 17:31, Bart Schaefer wrote: > > No. -m means to find all the names (in any hash table) that match a > pattern. -a means to show all the occurrences in $path of each name > (either literally without -m, or found in the command hash table by > -m). -m happens first, and then -a searches the path. That's a better explanation right there than in the docs. I was only saying how I think it should work, how it *does* work is only now made clear. > > Whether a full path appears there depends on how the function was > defined. The only way you get the output with "... from ..." but > without the full path is if you source the function from a file in the > current directory (e.g., "source rap"). Ah! so the full path information isn't even retained anywhere. Once it's in memory it doesn't matter. But if I do this: 2 /aWorking/Zsh/Source/Wk 5 $ . $(realpath ./rap) ... whence shows me this: rap is a shell function from /aWorking/Zsh/Source/Wk/rap ... because the full path is actually available at the time of sourcing. There is always a way.
On Mon, Oct 31, 2022 at 5:55 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> 2 /aWorking/Zsh/Source/Wk 5 $ . $(realpath ./rap)
Well, yes, but why not
...$ . $PWD:P/rap
P
Turn a file name into an absolute path, like realpath(3).