Re: 'whence' question

Re: 'whence' question

[Peter Stephenson]

On Wed, 05 Nov 2014 20:43:30 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Nov 5,  6:00pm, Peter Stephenson wrote:
> } Subject: Re: 'whence' question
> }
> } On Wed, 05 Nov 2014 18:49:23 +0100
> } Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> } > Looking at the source, it seems that whence doesn't support both -a and
> } > -m together though it doesn't produce an error.
> } 
> } You're right: I think *that's* a bug.
> 
> Hmm.  This is more complicated than it at first appears.

Moved to zsh-workers.

Don't we want something like this?

diff --git a/Src/builtin.c b/Src/builtin.c
index 5b711ed..101c19a 100644
--- a/Src/builtin.c
+++ b/Src/builtin.c
@@ -3228,11 +3228,39 @@ bin_whence(char *nam, char **argv, Options ops, int func)
 		scanmatchtable(builtintab, pprog, 1, 0, DISABLED,
 			       builtintab->printnode, printflags);
 	    }
-	    /* Done search for `internal' commands, if the -p option *
-	     * was not used.  Now search the path.                   */
-	    cmdnamtab->filltable(cmdnamtab);
-	    scanmatchtable(cmdnamtab, pprog, 1, 0, 0,
-			   cmdnamtab->printnode, printflags);
+	    if (all) {
+		char **pp, *buf, *fn;
+		DIR *od;
+
+		pushheap();
+		for (pp = path; *pp; pp++) {
+		    if (!**pp)
+			continue;
+		    od = opendir(*pp);
+		    if (!od)
+			continue;
+
+		    while ((fn = zreaddir(od, 0))) {
+			if (!pattry(pprog, fn))
+			    continue;
+
+			buf = zhtricat(*pp, "/", fn);
+
+			if (iscom(buf)) {
+			    zputs(buf, stdout);
+			    fputc('\n', stdout);
+			}
+		    }
+		    closedir(od);
+		}
+		popheap();
+	    } else {
+		/* Done search for `internal' commands, if the -p option *
+		 * was not used.  Now search the path.                   */
+		cmdnamtab->filltable(cmdnamtab);
+		scanmatchtable(cmdnamtab, pprog, 1, 0, 0,
+			       cmdnamtab->printnode, printflags);
+	    }
 
 	    unqueue_signals();
 	}

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: 'whence' question

[Bart Schaefer]

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

On Thu, Nov 6, 2014 at 1:10 PM, Peter Stephenson <
p.w.stephenson@ntlworld.com> wrote:

>
> Don't we want something like this?
>

Yes, we want something LIKE that, but simply calling zputs() doesn't handle
either the -v or the -s options, and it seems a shame to duplicate all that
code from the existing "if (all)" loop later in the function.

Re: 'whence' question

[Peter Stephenson]

On Thu, 6 Nov 2014 13:58:56 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Thu, Nov 6, 2014 at 1:10 PM, Peter Stephenson <
> p.w.stephenson@ntlworld.com> wrote:
> 
> >
> > Don't we want something like this?
> >
> 
> Yes, we want something LIKE that, but simply calling zputs() doesn't handle
> either the -v or the -s options, and it seems a shame to duplicate all that
> code from the existing "if (all)" loop later in the function.

I hadn't worked out which additional options -m handled	as it's all
hidden in functions.

It's not worth factoring out the common code; it would need a whole heap
of options passing in, passing back a value ignored in one case,
passing in both a string and a pattern where only one is used each
time...  Unless someone else can see a neater way.  Anyway, I will
commit this and someone else can apply their elegant optimisations.

The results would look better with a bit more sorting, but that's a
separate issue.

pws

diff --git a/Src/builtin.c b/Src/builtin.c
index 5b711ed..dd22d09 100644
--- a/Src/builtin.c
+++ b/Src/builtin.c
@@ -3228,11 +3228,47 @@ bin_whence(char *nam, char **argv, Options ops, int func)
 		scanmatchtable(builtintab, pprog, 1, 0, DISABLED,
 			       builtintab->printnode, printflags);
 	    }
-	    /* Done search for `internal' commands, if the -p option *
-	     * was not used.  Now search the path.                   */
-	    cmdnamtab->filltable(cmdnamtab);
-	    scanmatchtable(cmdnamtab, pprog, 1, 0, 0,
-			   cmdnamtab->printnode, printflags);
+	    if (all) {
+		char **pp, *buf, *fn;
+		DIR *od;
+
+		pushheap();
+		for (pp = path; *pp; pp++) {
+		    if (!**pp)
+			continue;
+		    od = opendir(*pp);
+		    if (!od)
+			continue;
+
+		    while ((fn = zreaddir(od, 0))) {
+			if (!pattry(pprog, fn))
+			    continue;
+
+			buf = zhtricat(*pp, "/", fn);
+
+			if (iscom(buf)) {
+			    if (wd) {
+				printf("%s: command\n", fn);
+			    } else {
+				if (v && !csh)
+				    zputs(fn, stdout), fputs(" is ", stdout);
+				zputs(buf, stdout);
+				if (OPT_ISSET(ops,'s'))
+				    print_if_link(buf);
+				fputc('\n', stdout);
+			    }
+			}
+		    }
+		    closedir(od);
+		}
+		popheap();
+	    } else {
+		/* Done search for `internal' commands, if the -p option *
+		 * was not used.  Now search the path.                   */
+		cmdnamtab->filltable(cmdnamtab);
+		scanmatchtable(cmdnamtab, pprog, 1, 0, 0,
+			       cmdnamtab->printnode, printflags);
+	    }
 
 	    unqueue_signals();
 	}

Re: 'whence' question

[Bart Schaefer]

On Nov 6,  1:58pm, Bart Schaefer wrote:
}
} Yes, we want something LIKE that, but simply calling zputs() doesn't
} handle either the -v or the -s options, and it seems a shame to
} duplicate all that code from the existing "if (all)" loop later in the
} function.

This is what I was thinking when I asked about ${(k)commands[(I)pat]}.
I wish there were a better way to make fetchcmdnamnode a closure, but
what you C is what you get ...


diff --git a/Src/builtin.c b/Src/builtin.c
index 5b711ed..c2af51f 100644
--- a/Src/builtin.c
+++ b/Src/builtin.c
@@ -3154,6 +3154,15 @@ bin_unset(char *name, char **argv, Options ops, int func)
 
 /* type, whence, which, command */
 
+static LinkList matchednodes;
+
+static void
+fetchcmdnamnode(HashNode hn, UNUSED(int printflags))
+{
+    Cmdnam cn = (Cmdnam) hn;
+    addlinknode(matchednodes, cn->node.nam);
+}
+
 /**/
 int
 bin_whence(char *nam, char **argv, Options ops, int func)
@@ -3165,7 +3174,7 @@ bin_whence(char *nam, char **argv, Options ops, int func)
     int aliasflags;
     int csh, all, v, wd;
     int informed;
-    char *cnam;
+    char *cnam, **allmatched = 0;
 
     /* Check some option information */
     csh = OPT_ISSET(ops,'c');
@@ -3198,6 +3207,10 @@ bin_whence(char *nam, char **argv, Options ops, int func)
 
     /* With -m option -- treat arguments as a glob patterns */
     if (OPT_ISSET(ops,'m')) {
+	if (all) {
+	    pushheap();
+	    matchednodes = newlinklist();
+	}
 	for (; *argv; argv++) {
 	    /* parse the pattern */
 	    tokenize(*argv);
@@ -3232,11 +3245,17 @@ bin_whence(char *nam, char **argv, Options ops, int func)
 	     * was not used.  Now search the path.                   */
 	    cmdnamtab->filltable(cmdnamtab);
 	    scanmatchtable(cmdnamtab, pprog, 1, 0, 0,
-			   cmdnamtab->printnode, printflags);
+			   (all ? fetchcmdnamnode : cmdnamtab->printnode),
+			   printflags);
 
 	    unqueue_signals();
 	}
-	return returnval;
+	if (all) {
+	    allmatched = argv = zlinklist2array(matchednodes);
+	    matchednodes = NULL;
+	    popheap();
+	} else
+	    return returnval;
     }
 
     /* Take arguments literally -- do not glob */
@@ -3244,7 +3263,7 @@ bin_whence(char *nam, char **argv, Options ops, int func)
     for (; *argv; argv++) {
 	informed = 0;
 
-	if (!OPT_ISSET(ops,'p')) {
+	if (!OPT_ISSET(ops,'p') && !allmatched) {
 	    char *suf;
 
 	    /* Look for alias */
@@ -3344,6 +3363,9 @@ bin_whence(char *nam, char **argv, Options ops, int func)
 	    returnval = 1;
 	}
     }
+    if (allmatched)
+	freearray(allmatched);
+
     unqueue_signals();
     return returnval;
 }

-- 
Barton E. Schaefer

Re: 'whence' question

[Bart Schaefer]

On Nov 8,  8:41pm, Peter Stephenson wrote:
}
} It's not worth factoring out the common code; it would need a whole
} heap of options passing in, passing back a value ignored in one case,
} passing in both a string and a pattern where only one is used each
} time...  Unless someone else can see a neater way.  Anyway, I will
} commit this and someone else can apply their elegant optimisations.

Cf. 33656.
 
} The results would look better with a bit more sorting, but that's a
} separate issue.

With 33653:

torch% noglob whence -m zsh*   
/usr/local/bin/zsh
/usr/local/bin/zsh-5.0.2-dev-0
/usr/local/bin/zsh-5.0.3
/usr/local/bin/zsh-5.0.4
/usr/local/bin/zsh-5.0.5
/usr/local/bin/zsh-5.0.7
/usr/local/bin/zsh.old
/etc/zshenv
/etc/zshrc
torch% noglob whence -am zsh*
/usr/local/bin/zsh-5.0.7
/usr/local/bin/zsh-5.0.3
/usr/local/bin/zsh
/usr/local/bin/zsh-5.0.4
/usr/local/bin/zsh.old
/usr/local/bin/zsh-5.0.5
/usr/local/bin/zsh-5.0.2-dev-0
/bin/zsh
torch% 

We've lost /etc/zshenv and /etc/zshrc in the -a case.  This isn't wrong,
because they're filtered out by iscom().  However:

torch% whence -mv zshenv 
zshenv is /etc/zshenv
torch% whence -av zshenv
zshenv not found
torch% whence -amv zshenv
torch% 

With 33656 the output of -amv is the same as -av in this latter case
(both print "zshenv not found").  Yes, an "else" could be added to the
"if (iscom(...))" in 33653 to get the "not found", but 33656 also
produces the -m sort order for -am when there is more than one match.

-- 
Barton E. Schaefer

Re: 'whence' question and others

[Ray Andrews]

On 11/09/2014 10:51 AM, Bart Schaefer wrote:

Gentlemen,

A few questions before I start applying patches:

Does it matter if we 'make' from the Src directory vs. from it's parent?
It seems to work either way.

How often does one have to './configure'?

Rebuilding from virgin source, I ended up with a different size for zsh,
that's a bit scary, is it ok, or did I manage to farkle something? The 
new sized
build has been running without obvious trouble for several days.

Original:
-rwxr-xr-x 1  708980 2014-10-22//19:16:30 Src/Virgin/zsh*
Used for several days:
-rwxr-xr-x 1 711892 2014-11-04//19:59:26 
/usr/local/bin/zsh-test2-orig-rebuild*
Rebuilt just now:
-rwxr-xr-x 1  711860 2014-11-09//21:00:54 Src/zsh*


Where does one find function help in gcc?  I'm still using my ancient 
Borland C
manuals.

I managed to create a bit of a disaster with my 'printf()s' used for 
tracing, several
system files were trashed, which isn't exactly surprising, since so many 
files
can be open.  Would "fprintf(stderr, ..." be any safer?  What's the 
standard way of
doing that sort of thing?  I still think like a DOS man.

    utils.c:(.text+0x344e): warning: the use of `mktemp' is dangerous, 
better use `mkstemp' or `mkdtemp'

Anything to learn from the warning?  Can it be got rid of?

Re: 'whence' question and others

[Bart Schaefer]

On Sun, Nov 9, 2014 at 9:15 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Does it matter if we 'make' from the Src directory vs. from it's parent?
> It seems to work either way.
>
> How often does one have to './configure'?

If you build from the parent directory, configure will be (re)run when
necessary by "make".  Also in that case, the documentation will be
rebuilt when the .yo files are changed.

> Rebuilding from virgin source, I ended up with a different size for zsh,
> that's a bit scary, is it ok, or did I manage to farkle something?

All sorts of things might account for a few bytes difference in the
size of the executable.  Unless it came out very different I wouldn't
be concerned.

> Where does one find function help in gcc?

What exactly do you mean by "function help"?  The documentation for
the library functions?  On most linux systems "info libc" will
probably work (if you aren't familiar with the "info" viewer, type "?"
after it starts up for help).  There may also be a "tkinfo" which is a
GUI for browsing info documentation.

If "info" doesn't work try "man functionname" for whatever specific
function you are seeking.  You want the pages in sections 2 or 3 of
the manual, not section1.

> I managed to create a bit of a disaster with my 'printf()s' used for
> tracing, several system files were trashed

Oh dear.  I didn't realize the zsh you were installing for regular use
was the same one where you inserted tracing statements.  I would
strongly advise against doing that.

> Would "fprintf(stderr, ..." be any safer?  What's the standard
> way of doing that sort of thing?  I still think like a DOS man.

Yes, stderr would be safer, though of course it can still be redirected.

If you configure with --enable-zsh-debug then a function dputs() is
available which writes messages to the file named by the
$ZSH_DEBUG_LOG parameter.  It's kind of a stripped-down printf() which
accepts only a few %-formats:  %s = string, %d = int, %L = long, %c =
char (including multibyte), %e = error number [for strerror()], and %l
which is for non-nul-terminated strings and accepts two arguments, the
char* and the number of bytes to print.  If you want to leave some
kind of tracing on during normal use, I would recommend using dputs()
and setting $ZSH_DEBUG_LOG.  There are also a set of DPUTS() macros
which are sort of like assert() wrappers for dputs().

Something akin to the above paragraph ought to be in
zsh-development-guide somewhere.

>    utils.c:(.text+0x344e): warning: the use of `mktemp' is dangerous, better
> use `mkstemp' or `mkdtemp'
>
> Anything to learn from the warning?  Can it be got rid of?

It's sort of spurious.  Zsh uses mktemp() in a safe way.  The warning
is just letting you know that it can be a problem if you don't know
what you're doing.

Re: 'whence' question and others

[Bart Schaefer]

On Mon, Nov 10, 2014 at 12:20 AM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> Something akin to the above paragraph ought to be in
> zsh-development-guide somewhere.

By which I mean it is NOT there but should be added.

Re: 'whence' question

[Peter Stephenson]

On Sat, 08 Nov 2014 13:55:08 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Nov 6,  1:58pm, Bart Schaefer wrote:
> }
> } Yes, we want something LIKE that, but simply calling zputs() doesn't
> } handle either the -v or the -s options, and it seems a shame to
> } duplicate all that code from the existing "if (all)" loop later in the
> } function.
> 
> This is what I was thinking when I asked about ${(k)commands[(I)pat]}.
> I wish there were a better way to make fetchcmdnamnode a closure, but
> what you C is what you get ...

I'm not that much bothered what the code looks like, the question seems
to be more what the result should be consistent with.  If you've worked
that you can decide what needs doing.

pws

Re: 'whence' question and others

[Ray Andrews]

On 11/10/2014 12:20 AM, Bart Schaefer wrote:

> If you build from the parent directory, configure will be (re)run when 
> necessary by "make". Also in that case, the documentation will be 
> rebuilt when the .yo files are changed. 


Is there a decent doc for 'configure', what it does, how it works? I see 
the msg. scroll by,
and they are mostly about what is and isn't available.  One can easily 
understand that
there'd be a check for essential stuff, but it seems do do much more 
than that. What makes
a reconfigure necessary?

> What exactly do you mean by "function help"? The documentation for the 
> library functions? On most linux systems "info libc" will probably work

Tx.  Once I got the proper name of the lib from that the rest was easy.

> If you configure with --enable-zsh-debug then a function dputs() is 
> available which writes messages to the file named by the 
> $ZSH_DEBUG_LOG parameter. It's kind of a stripped-down printf() which 
> accepts only a few %-formats: %s = string, %d = int, %L = long, %c = 
> char (including multibyte), %e = error number [for strerror()], and %l 
> which is for non-nul-terminated strings and accepts two arguments, the 
> char* and the number of bytes to print. If you want to leave some kind 
> of tracing on during normal use, I would recommend using dputs() and 
> setting $ZSH_DEBUG_LOG. There are also a set of DPUTS() macros which 
> are sort of like assert() wrappers for dputs(). Something akin to the 
> above paragraph ought to be in zsh-development-guide somewhere. 

Good, some nice robust methods.

Re: 'whence' question and others

[Vin Shelton]

Hi, Ray -

On Mon, Nov 10, 2014 at 11:57 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> Is there a decent doc for 'configure', what it does, how it
> works? I see the msg. scroll by, and they are mostly about what
> is and isn't available. One can easily understand that
> there'd be a check for essential stuff, but it seems do do much
> more than that. What makes a reconfigure necessary?

Autoconf is a set of scripts designed to ensure application
portability across multiple platforms.  autoconf's homepage is:
https://www.gnu.org/software/autoconf/ .  The autoconf manual is here:
https://www.gnu.org/software/autoconf/manual/index.html .

HTH,
  Vin

Re: 'whence' question

[Ray Andrews]

Got that patch.  It works as advertised but I noticed this:

    $ whence -vam "zsh*"                       << QUOTED
    zsh is an alias for /usr/local/bin/zsh
    zshh is an alias for /usr/local/bin/zsh    << CATCHES ALIAS
    zsh-RayStyle1 is a shell function       << CATCHES FUNCTION
    zshh is a shell function                      << CATCHES FUNCTION
    zshh is /usr/local/bin/zshh                    << CATCHES SCRIPT
    zsh is /usr/local/bin/zsh
    zsh-RayStyle1 is /usr/local/bin/zsh-RayStyle1    << CATCHES BINARY
    zsh is /usr/bin/zsh
    zsh is /bin/zsh

    $ whence -vam zsh*                        << UNQUOTED
    zsh is an alias for /usr/local/bin/zsh
    ?  zshh  ...                                        << MISSES ALIAS
    ?   zshh ...                                        << MISSES FUNCTION
    ?   zshh ...                                         << MISSES SCRIPT
    zsh is /usr/local/bin/zsh
    zsh is /usr/bin/zsh
    zsh is /bin/zsh
    zsh-RayStyle1 is a shell function                        << CATCHES
    FUNCTION
    zsh-RayStyle1 is /usr/local/bin/zsh-RayStyle1        << CATCHES BINARY

I know that '-m' arguments are supposta be quoted, but, apart from the 
above,
I haven't found any situation where it seems to make any difference.  
Why would
it miss 'zshh' but find 'zsh-RayStyle1', and why do the quotation marks 
change
the order?

binary 'zsh-RayStyle1' might be found in both cases because it's linked:

     lrwxrwxrwx 1      28 2014-11-10//13:39:57 zsh -> 
/usr/local/bin/zsh-RayStyle1*

... but it still seems strange.  And the situation with the aliases and 
functions is
hard to understand. Both functions just echo their own name, so it's not 
the
contents.  For now the moral of the story is to always quote, but why would
one ever *not* quote?  I mean is there some valid use of it unquoted, or 
is that
just always wrong?  If always wrong, they can we 'autoquote' some how?
Complicated! And there's always another gotcha.

The above is not rigorous, but any clarification is welcome.

Re: 'whence' question

[Ray Andrews]

ALL GOOD:

$ whence -vam "zsh*"
zsh is an alias for /usr/local/bin/zsh
zshh is an alias for /usr/local/bin/zsh
zsh is /usr/local/bin/zsh
zsh-RayStyle1 is /usr/local/bin/zsh-RayStyle1
zsh is /usr/bin/zsh
zsh is /bin/zsh

FIRST OCCURRENCE  OF FILES ONLY? I'D EXPECT THE '-m' FORM TO BE
THE DEFAULT, THE DOC IS CLEAR THAT ALL COMMAND FORMS ARE
SEARCHED.

$ whence zsh*
/usr/local/bin/zsh
/usr/local/bin/zsh-RayStyle1

HERE, QUOTATION BREAKS IT :(

$ whence  "zsh*"
(nothing)

Who tested all this stuff back in the day?

ALL GOOD:

$ whence -vasm "zsh*"
zsh is an alias for /usr/local/bin/zsh
zshh is an alias for /usr/local/bin/zsh
zsh is /usr/local/bin/zsh -> /usr/local/bin/zsh-RayStyle1
zsh-RayStyle1 is /usr/local/bin/zsh-RayStyle1
zsh is /usr/bin/zsh -> /usr/local/bin/zsh-RayStyle1
zsh is /bin/zsh -> /usr/local/bin/zsh-RayStyle1

REMOVE  '-v' AND ALIASES 'BECOME' FILES! :(
THIS ISN'T BROKEN BUT IT SURE ISN'T HELPFUL EITHER.
WITHOUT '-v' ONE CAN GET VERY MISLED, BUT CAN THAT BE HELPED?

$ whence -asm "zsh*"
/usr/local/bin/zsh << THIS IS AN ALIAS!
/usr/local/bin/zsh << THIS IS AN ALIAS NAMED zshh !!!!
/usr/local/bin/zsh -> /usr/local/bin/zsh-RayStyle1
/usr/local/bin/zsh-RayStyle1
/usr/bin/zsh -> /usr/local/bin/zsh-RayStyle1
/bin/zsh -> /usr/local/bin/zsh-RayStyle1

Re: 'whence' question

[Bart Schaefer]

On Tue, Nov 11, 2014 at 8:52 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> Got that patch.  It works as advertised

If you haven't already, you might want to get minimally familiar with
"git" so you can pull from the development repository rather than
applying individual patches.

> but I noticed this:
>
>    $ whence -vam zsh*                        << UNQUOTED

What's happening here is that zsh* is being expanded as a file glob in
the local directory, and then "whence" is being called with the
resulting file names as arguments and looking up each of them in turn.
Try

$ echo whence -vam zsh*

and see what you get.  I think this will explain all your confusion.

> For now the moral of the story is to always quote, but why would
> one ever *not* quote?

For "whence" one probably would always quote patterns.  For most other
commands that operate on file names, one probably wants them unquoted,
so that is the default behavior.  Command line input semantics
including globbing are entirely separate in *nix from the semantics
internal to the command itself -- very unlike DOS where it is up to
the command to invoke globbing on its arguments.

> I mean is there some valid use of it unquoted, or is that
> just always wrong?  If always wrong, they can we 'autoquote' some how?

You could use

alias whence='noglob whence '

(the trailing space is important, see the description of the "alias" command).

Re: 'whence' question

[Bart Schaefer]

On Tue, Nov 11, 2014 at 10:16 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> FIRST OCCURRENCE  OF FILES ONLY? I'D EXPECT THE '-m' FORM TO BE
> THE DEFAULT, THE DOC IS CLEAR THAT ALL COMMAND FORMS ARE
> SEARCHED.

I'm not sure what you're hollering about.  Searching all forms has
nothing to do with whether the search is for a literal string (which
is the default) or for a pattern (which requires the -m option to be
explicitly stated).  "All command forms" means aliases, reserved
words, and functions, and your example found those aliases.

> $ whence zsh*
> /usr/local/bin/zsh
> /usr/local/bin/zsh-RayStyle1

I'm 99.75% sure that you'd see

$ echo zsh*
zsh
zsh-RayStyle1

and that this is entirely the reason you get the above result from whence.

> $ whence  "zsh*"
> (nothing)

Well, yeah.  You did not specify -m and there is no command or
function whose name literally is zee ess aitch star, so whence found
nothing.

> REMOVE  '-v' AND ALIASES 'BECOME' FILES! :(

Well, no, they don't become files, the become whatever is on the
right-hand-side of the alias.

% alias zsh='echo good golly miss molly'
% whence -a zsh
echo good golly miss molly
/bin/zsh

It's not the fault of "whence" that you don't find this to be as
useful as the -v output.

Re: 'whence' question

[Bart Schaefer]

On Tue, Nov 11, 2014 at 11:14 AM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> You could use
>
> alias whence='noglob whence '
>
> (the trailing space is important, see the description of the "alias" command).

And of course I botched this, the trailing space should NOT be there
for "whence" because you want "whence" itself to do the alias lookup.
Sorry.

Re: 'whence' question

[Ray Andrews]

On 11/11/2014 11:14 AM, Bart Schaefer wrote:
> On Tue, Nov 11, 2014 at 8:52 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>> Got that patch.  It works as advertised
> If you haven't already, you might want to get minimally familiar with
> "git" so you can pull from the development repository rather than
> applying individual patches.
Right, I just wanted to have a chew on that patch first.  Tricky doing 
it by hand,
gotta learn to do it correctly.
> and see what you get.  I think this will explain all your confusion.
Well, lots of it anyway ;-) in the case of:

     $ whence zsh*
     zsh
     /usr/local/bin/zsh-RayStyle1

... it was just a coincidence that a copy of the latter file was in my 
current dir, thus
a subject for search.  It wasn't 'really' scanning the path for "zsh*" 
in the same
way that it would with '-m' active. I got the results I expected, but 
for absolutely
the wrong reasons.)
>
> For "whence" one probably would always quote patterns.  For most other
> commands that operate on file names, one probably wants them unquoted,
> so that is the default behavior.  Command line input semantics
> including globbing are entirely separate in *nix from the semantics
> internal to the command itself -- very unlike DOS where it is up to
> the command to invoke globbing on its arguments.
Ok, I think I get it.  That's the difference between quoted and unquoted 
arguments to
whence or anything else.  One might validly leave ' zsh* ' unquoted, but 
the meaning
is very different.  I should already have that written in my DNA, pardon 
for being
thick headed.

Re: 'whence' question

[Ray Andrews]

On 11/11/2014 11:33 AM, Bart Schaefer wrote:

> I'm not sure what you're hollering about. 

Ah.  Not hollering, just distinguishing comment from output.  I composed 
that outside of
email.
> Searching all forms has
> nothing to do with whether the search is for a literal string (which
> is the default) or for a pattern (which requires the -m option to be
> explicitly stated).  "All command forms" means aliases, reserved
> words, and functions, and your example found those aliases.
All answered in last post Bart, thanks.

>
> REMOVE  '-v' AND ALIASES 'BECOME' FILES! :(
> Well, no, they don't become files, the become whatever is on the
> right-hand-side of the alias.
Of course. I just meant that one could easily get confused.
> It's not the fault of "whence" that you don't find this to be as
> useful as the -v output.
Sure, I mentioned that myself, it isn't broken, if one wants clarity, 
use '-v'.
That's just a vague 'editorial' sort of remark, that perhaps the default 
behavior
might have been the more explicit output. It's subjective. I guess that 
culturally,
zsh builds power up from components rather than trying to be fancy by 
default.
That's cool.

All issues answered, as usual.  Sorry again for being dense.