Re: could there be a bash built-in that allows executing readline functions?

[Chet Ramey]

On 10/23/23 5:53 PM, Christoph Anton Mitterer wrote:
> On Mon, 2023-10-23 at 15:15 -0400, Chet Ramey wrote:
> > What makes that superior to something like a readline function to
> > execute
> > a named readline command, like M-x does in emacs?
>
> AFAIU, the following applies:
>
> - users may use multiple programs, that may change keybindings

How does this matter? We're talking about a bash-specific solution here.
If there were a key binding that was, by default, bound to something
like execute-named-command, wouldn't it be the user's responsibility if
they bound it to something else? (Not any fault, but they couldn't expect
it to work as documented, could they?)

> at least with respect to the use case that I was talking about in this
> thread:
>
> - the approach suggested by Koichi:
>      bind    '"\ec":    "\xC0\a\xC0\r\xC0\n"'
>      bind -x '"\xC0\a": store_and_set'
>      bind    '"\xC0\r": accept-line'
>      bind -x '"\xC0\n": restore_and_set'
>    which uses the first in that list to guarantee that the following are
>    executed in that order and with nothing in between, set up these
>    bindings once statically.

I've only been following this discussion casually, but this approach
seems reasonable.


>    That it works itself (and doesn't break anything else) depends fully
>    on the likeliness that one uses keyseqs that no-one else use.

How likely do you think this is?

>    Chances may be small, yes, but still seems a risk I wouldn't want to
>    be responsible for.

Even if you were to document the bindings this approach uses (which may
be an arbitrary number of characters)?

> - "my" approach:
>       bind -x '"\ec":    store_and_set'
>       bind    '"\e[0n":  "\xC0\r\xC0\a"'
>       bind    '"\xC0\r": accept-line'
>       bind -x '"\xC0\a": restore_and_set'
>     with store_and_set and set eventually printing \e[5n ...
>     has the advantage that it can set all binds other than the main one
>     (\ec) in store_and_set, where it also removes all other bindings to
>     make sure that nothing is in the queue right after \ec and with
>     some tricks one can IMO even prevent any bigger damage in case any
>     of the 3 other bindings were in the queue.
>     By restoring the original bindings, the shell should never see
>     any other binding than the one for \ec, so one can avoid to
>     accidentally break other stuff.

This seems to be the key concern.

>     But, that requires numerous hacks (fragile stuff like
>     storing/restoring/removing all bindings, which may fail with any
>     bash version).
>     It may no work as expected when the function is interrupted by some
>     signal (e.g. leave back the shell with no bindings at all).
>     And, as Koichi pointed out, requires a round-trip with the terminal
>     (which I guess in may in principle not even support the
>     \e[5n -> \e[0n).
>
> Both suffer from the problem, that PROMPT_COMMAND or PS1 (and perhaps
> even by other means I'm not aware of) the bindings may be broken again,
> after the accept-line.

If the user does this, how can your code be responsible? Anyone can
override any readline keybinding, and I don't feel responsible if
someone binds something new to, say, ^A.


> My hope was - and of course I may be totally wrong - that a built-in
> that allows me to execute the accept-line from the function would make
> all the voodoo unnecessary and be safe in all cases, like that:
>    bind -x '"\ec": dir="$(find) | fzf)"; store_current_readline; 
> READLINE_LINE="$dir";   magic_built_in accept-line;   restore_old_readline'
>
> No multiple bindings needed, no fragile functions, no awk, sed, whatsoever.

It might make some things easier. I'm not convinced about the safety
concerns.


> Before I've ended up asking on help-bash for help, I did of course
> search for solutions on stackoverflow and the likes.
> Seems, that there were quite some questions like "how can one execute
> two readline functions in a row".

Using a macro with key bindings?

Let's conduct a thought experiment. Say I added some new option to `bind'
for this (this clearly does not deserve its own builtin). Under what
conditions should it execute? What should it assume about readline's
state or the state of the objects readline exports (line buffer, etc.)?
The executing part is easy: take a string, look up a function, and
execute it. But how do you want to guarantee it executes on something
reasonable?

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/