Re: [PATCH 1/4] run-help: Support variables in aliases

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

> On 17/05/2023 23:45 Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> 
>  
> On Wed, May 17, 2023 at 3:13 PM Jörg Sommer <joerg@xxxxxxxx> wrote:
> >
> > If the alias definition starts with a variable assignment, run-help fails,
> > because it sees the variable assignment as command. Hence, skip all
> > variable assignments and noglob|nocorrect thereafter.
> 
> This may not be the right way to handle this.  The same thing is
> already being attempted in the block at
> 
>     (*)
>         if ((! didman++))
>         then
> 
> where you'll see
> 
>                 # Discard the command itself & everything before it.
> 
> so I would have expected the existing recursive call to cover it.

I think the key thing here is the line

	    if whence "run-help-$1:t" >/dev/null

so the bit you're talking about is only run if $1 has a run-help
subfunction.  Obviously this isn't Jörg's case.

What's going on at this point is a bit obscure, but I'm not
convinced the "discard options, parameter assignments and
paths" has anything to do with the zsh common line handling.
I think it's getting rid of anything in the arguments to the
command with the specialised run-help that might not help
the run-help-blah work.  So something like

mycmd var=var1 subcmd

is munged to run

run-help-mycmd subcmd

> If
> recursion is NOT handling it, then maybe we need to pull that whole
> thing up to before the original "whence" command?

I think this is actually an entirely different case, but someone
could authoritatively tell me I'm wrong.

pws