Re: psychiatric help

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Apr 6, 2026 at 7:18 AM Ray Andrews <rayandrews@xxxxxxxxxxx> wrote:
>
> On 2026-04-05 22:03, Bart Schaefer wrote:
> > zle-line-finish is a "special" widget that ZLE runs automatically just
> > after accept-line (the widget normally bound to Enter/Return).  By
> > default it's not defined at all, so you have to create it.
> Ah!  Like preexec() -- IF it exists it will be executed.  Yes?

Yes.

> > zle -N zle-line-finish _tt
> > Like that.
> Not to split hairs, but does that append _tt or cause _tt to be absorbed
> into zle-line-finish?

Ir replaces zle-line-finish with _tt.  There's another mechanism
called "hooks" for chaining together a series of functions all run at
the time of the zle-line-finish event, but get your head around the
single function first.

> As you say, the latter doesn't exist, so this
> creates it but with the contents of _tt?  But zle-line-finish can't be
> found even after the above is executed.

You're probably looking in the wrong place.  Widgets aren't in the
same namespace as shell functions.  To see the widget, use

% zle -l
zle-line-finish (_tt)

> function ttt ()
> {
> BUFF=${(z)BUFFER} # I just need access, I don't need it actually on the CL.

Er, no.  (z) creates an array, if you're going to assign it as a
scalar you would just do
  BUFF=$BUFFER
but what you really want is
  BUFF=( ${(z)BUFFER} )

> export BUFF

BUFF is already a global (because you didn't declare it local).  You
don't want or need to export it.

> }
> zle -N zle-line-finish ttt

If that's all you're going to do you might as well stick with precmd.
The point of using zle-line-finish would be to eventually assign
something back to BUFFER again.

> alias l='noglob _l'
> function _l ()
> {
> echo "\nMy name is $BUFF[1]
> and my unexpanded tail is: ${BUFF[2,-1]}"

This will work if BUFF is an array, but not when it's a scalar.

> ... when I first threw myself at this issue, the simple idea was to just
> retrieve the command line from history:
>
> $  history -rn -1
>
> ... but the line in history and the above $BUFF method have the exactly
> same problem, namely when there's more than one command on the line.

You're asking for two mostly-incompatible things.  ZLE and history can
be thought of as both working on units of user input, "tails" are in
units of individual commands.

> The real goal here is to get the unexpanded tail of each command
> separately.  But perhaps zsh expands the whole line in one go rather
> than first break the line into separate commands, and then do the
> expansion?

It's a lot more complicated than this, but you can think of it as
  1) Accept the input from the current prompt
  2) Expand all the aliases
  3) Repeat:
    a) Gather everything up to a command separator
    b) Expand all the globs and variables
    c) Run the command from the first word

You are looking for a cross of what's just after (1) with what's just
after (3a), except that you want to access it in the middle of (3c).
That doesn't exist anywhere.  When there's only a single command, you
can fake it by looking at the "tail" of $BUFFER, but if you want it
for a complex command you're on your own to repeat the equivalent of
(3a) on the contents of $BUFFER to pick out the individual "tails"
before you reach (2).

Your current hack uses "noglob" at (2) to bypass some of (3b) and then
"eval" inside (3c) to run a different command than what appeared at
(1).  That may be the best you can do, but as you've noted it tends to
be fragile around quoting and doesn't really get you exactly what
you're seeking.

> Unless ... each command sequentially bit off its own chunk of $BUFF, up
> to the semicolon, leaving the next command unambiguously looking at the
> next: 'command' 'tail' 'semicolon'.  Should be easy?

You're implementing a shell command parser in shell commands.  Ask the
folks who implemented zsh syntax highlighting in ZLE how easy that
was.