w2022年11月15日(火) 5:31 Chet Ramey <chet.ra...@case.edu>:
> On 11/14/22 11:40 AM, Koichi Murase wrote:
> > 2022年11月15日(火) 0:22 Chet Ramey <chet.ra...@case.edu>:
> >> On 8/11/22 5:56 PM, Koichi Murase wrote:
> >>> Can we also change the behavior of TERM in a similar way with option
> >>> 4? Currently, a temporal change of TERM clears keybindings of some
> >>> keys (home, end, right, left, etc.) even when the temporal change does
> >>> not survive across multiple calls of readline:
> >>
> >> I finally got back to look at this, and I couldn't reproduce it. That was
> >> expected, since the arrow key binding functions are pretty careful not to
> >> overwrite an existing binding. Then I figured out what was going on.
> >
> > Thank you for checking this.
> >
> >>>
> >>> $ bash-dev --norc
> >>> $ echo "$TERM"
> >>> screen.xterm-256color
> >>> $ bind '"\e[1~": bell'
> >>
> >> This unbinds the key sequence, since `bell' is not a valid bindable command
> >> name.
> >
> > Ah, OK. The above ``reduced case'' was not correct, but unbinding is
> > actually what I wanted to do in the original problem. In the original
> > code, I intentionally unbind the keybinding for "\e[1~" and instead
> > try to bind a single byte `\e'.
>
> What do you try to bind \e to?
For my particular case, I would like to decode the escape sequences by
myself within the shell code using « bind -x '"\e": shell-func' » to
provide another configuration interface for the terminal's specific
key sequences and keybindings. I must admit that my use case is
unusual, but I am not sure if we could say for sure that there would
never be any use cases of binding to `\e' other than that.
> >> I think the "TERM=$TERM" idiom to reset the readline terminal settings
> >> without overwriting existing key bindings is useful enough to retain the
> >> current behavior.
> >
> > I think it can be useful, but should that also apply to the tempenv of
> > the form "TERM=$TERM infocmp"?
>
> You can't really have one without the other, given the way the special
> variable handling works (and has worked).
>
> > In the sense that the side effects of
> > the temporary environment variables (tempenvs) are intended to be not
> > persistent after the execution of the command (unless it is for
> > special builtin and functions in the POSIX mode), I would like to
> > request that the idiom TERM=$TERM to reset the terminal settings would
> > not be invoked for the tempenvs.
>
> The variables in the temporary environment are restored to their previous
> values after the command executes. It's that restoration that triggers the
> call to rl_reset_terminal(), not the environment assignment, undoing any
> side effects of the environmnent assignment. Bash treats these uniformly,
> whether the simple command is a builtin, function, or command from the
> file system.
>
> So from readline's perspective, there is no difference between TERM=xxx
> and 'TERM=xxx command'. rl_reset_terminal() gets called the same way from
> the same function in both cases.
I would not think the fix would be an easy "single-line" fix either,
but is it impossible to get the context of setting the variable inside
sv_terminal (variables.c:6046) e.g. by checking the variable contexts
where TERM{,CAP,INFO} are defined or by adding the second parameter to
sh_sv_func_t? Maybe it could be more complicated than I initially
thought: For example, we need to care about the case « TERM=xxxx read
-e » where we need to finally set up the terminal settings for
readline. We also need to handle att_propagate (variables.c:134) for
the cases like « TERM=xxxx export TERM » where the value of the
tempenv would be propagated to the original scope.
--
Koichi
