Re: [PATCH v2] run-help for docker, perf, podman, ssh, svnadmin

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Sep 23, 2023 at 2:17 AM Jörg Sommer <joerg@xxxxxxxx> wrote:
>
> Oliver Kiddle schrieb am Do 21. Sep, 00:41 (+0200):
> > The other was 51746 which did elicit a couple of less than enthusiastic
> > replies.
>
> I guess you talk about “run-help: Support variables in aliases”. This
> discussion was entrenched and no solution was found.

Returning to that below ... meanwhile:

> I still have the
> problem of
>
> ```
> % unalias run-help
> % autoload run-help
> % alias tt1='LC_ALL=C true' tt2=true
> % run-help tt2
> tt2 is an alias for true
> % run-help tt1
> tt1 is an alias for LC_ALL=C true
> LC_ALL=C not found
> No manual entry for LC_ALL=C
> ```

This works for me in the current dev version, that is, after
workers/51593 is applied.

What continues not to work is your original example of an alias that
invokes another alias, where the first alias is nothing but an
assignment:

> zenbook% alias LCC='LC_ALL=C'; alias T='LCC true'
> zenbook% run-help T
> No manual entry for T
> ```

(the above excerpted from the message quoted below)

On Thu, 18 May 2023 08:52:21 +0200 Jörg Sommer <joerg@xxxxxxxx> wrote:
>
> Bart Schaefer schrieb am Wed 17. May, 15:45 (-0700):
> >                 # Discard the command itself & everything before it.
> >
> > so I would have expected the existing recursive call to cover it.  If
> > recursion is NOT handling it, then maybe we need to pull that whole
> > thing up to before the original "whence" command?

I'm leaning toward this being the way to go.  However, in retrospect,
Marlon's trick for skipping leading assignments, etc., begins to look
more ad-hoc than necessary.  I suspect we should instead disassemble
the command with ${(z)...} and look at the arguments one by one.

> zenbook% alias LCC='LC_ALL=C'; alias T='LCC true'

This is going to be a messy problem either way because this looks like
a command named "LCC" that happens to take an argument "true".  The
only way for run-help to discover that it should be invoking help for
"true" is to recursively expand all aliases before analyzing the
command line ... but in that case it can't report "... is an alias for
...".  I would more likely expect this --

> zenbook% run-help T

-- to at best respond with something like --

T is an alias for LCC true
LCC is an alias for LC_ALL=C

-- and then stop.

> > I repeat my earlier remarks about "reaching the point of diminishing
> > returns" with our attempts to turn run-help into a full command-line
> > parser.
>
> I see. That's a fair point. What would be a better attempt to support
> variables in aliases?

To start with, an additional flag to ${(Z+opts+)var} that would expand
aliases could be very helpful.  Other than that, the suggestion above
to use (z) or one of it's variations (do we handle both possible
settings of interactivecomments?) might make it easier to search for
command words.