From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25952 invoked by alias); 1 Apr 2018 04:30:11 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 23298 Received: (qmail 11260 invoked by uid 1010); 1 Apr 2018 04:30:11 -0000 X-Qmail-Scanner-Diagnostics: from mta01.eastlink.ca by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(24.224.136.30):SA:0(-1.9/5.0):. Processed in 15.176475 secs); 01 Apr 2018 04:30:11 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_RP_MATCHES_RCVD,T_SPF_HELO_TEMPERROR autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: rayandrews@eastlink.ca X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=utf-8; format=flowed X-Authority-Analysis: v=2.3 cv=dfKuI0fe c=1 sm=1 tr=0 a=RnRVsdTsRxS/hkU0yKjOWA==:117 a=RnRVsdTsRxS/hkU0yKjOWA==:17 a=IkcTkHD0fZMA:10 a=Xo3g73Xir8Uk06UqfZkA:9 a=QEXdDO2ut3YA:10 X-EL-IP-NOAUTH: 24.207.101.9 Subject: Re: whence (was Re: local unfunction) To: zsh-users@zsh.org References: <6935145d-785f-f2dd-d4f2-e7ea627e2bc3@eastlink.ca> From: Ray Andrews Message-id: <4fd81a57-30af-2e07-3be5-076826cce844@eastlink.ca> Date: Sat, 31 Mar 2018 21:29:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 In-reply-to: Content-language: en-CA On 31/03/18 06:18 PM, Bart Schaefer wrote: > > What's with the extra ":" there? Is there actually a colon in the file name? It's deliberate abuse, I tried all sorts of things to see what might work and what might break.  It seems there's nothing in my issues that's  directly caused by some sort of weird naming . > -m # find all matches of a pattern, subsumes '-a' (executable ONLY unless I meant it might be so not that it is so. > This being a proposed new flag. I think this points to the source of > the confusion. The command hash table will contain the first > occurrence of every file name from every directory in $path, even if > that first occurrence is not executable, and "whence -m" will show you > all of the matching entries in the hash table. The existing -m option > subsumes your -t. > > The other confusion is that -m never searches $path. It always > populates the command hash table if necessary and then searches the > hash table. I dunno Bart, it all seems so counter intuitive.  Maybe it's just me, but my 'interpretation' seems the natural one.  It seems absolutely robust as far as aliases and functions and everything but files, but with files, one never knows what might be found.  At the very least the docs could be a bit more clear.  But as I said, I seem to be the only one chaffing about this so I'll use other means to find matching files on the path and make a clear distinction between executables and non executables.  The output of my wrapper, unverbose, looks like this: $ i "zsh*" 146:: (1)TYPE: /aWorking/Zsh/Source/Wk/zsh is an unexecutable script or text file 146:: (2)TYPE: /aWorking/Zsh/System/zsh is an unexecutable script or text file 146:: (3)TYPE: /aWorking/Bin/zsh5.3.txt is an unexecutable script or text file 196:: (1)TYPE: zsh is /usr/local/bin/zsh -> /aWorking/Bin/zsh5.3: 196:: (2)TYPE: zsh is /usr/bin/zsh -> /aWorking/Bin/zsh5.3: 196:: (3)TYPE: zsh is /bin/zsh -> /aWorking/Bin/zsh5.3: ... it finds every damn thing every time no buts or maybes and I'm expecting it to work in April too except when the moon is waning ;-) $ i grep 196:: (1)TYPE: GREP is an alias for grep $g_nocase --color=auto: 196:: (2)TYPE: grep is /bin/grep: $ i echo 196:: (1)TYPE: echo is a shell builtin: 196:: (2)TYPE: echo is /bin/echo: