why can't we use "vared" in a subshell in interactive shells?

why can't we use "vared" in a subshell in interactive shells?

[Stephane Chazelas]

Hi,

from
https://unix.stackexchange.com/questions/565718/zsh-timeout-for-vared-builtin/566442?noredirect=1#comment1053418_566442

In a script, both

vared myvar

and

(vared myvar)

work, but in an interactive shell, the latter doesn't:

$ (vared -c var)
vared: ZLE not enabled

Why?

The code indeed has:

    if ((interact && unset(USEZLE)) || !strcmp(term, "emacs")) {
        zwarnnam(name, "ZLE not enabled");
        return 1;
    }

And entersubsh() has

    opts[USEZLE] = 0;
    zleactive = 0;


-- 
Stephane

Re: why can't we use "vared" in a subshell in interactive shells?

[Bart Schaefer]

On Sat, Feb 8, 2020 at 11:37 AM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> $ (vared -c var)
> vared: ZLE not enabled
>
> Why?

Looks like an overlooked side-effect to me.  The assumption being made
is that in interactive mode, if USEZLE is false then it's because the
user has explicitly unsetopt'd it, not because it was temporarily
disabled on entry to a subshell.

There are two ways we could go here:
1) Assume that if the user has invoked vared, then it's OK to run ZLE
even if it was otherwise turned off, and just remove that test
entirely.  (The check for TERM == emacs is mostly obsolete anyway, if
we're attempting to do that we should be looking for [absense of]
certain terminfo values, not a specific terminal type.)
2) Figure out some way to remember the old state of USEZLE when
entering the subshell, and check that in bin_vared instead of checking
the current state.

Re: why can't we use "vared" in a subshell in interactive shells?

[Stephane Chazelas]

2020-02-08 13:23:46 -0800, Bart Schaefer:
[...]
> Looks like an overlooked side-effect to me.  The assumption being made
> is that in interactive mode, if USEZLE is false then it's because the
> user has explicitly unsetopt'd it, not because it was temporarily
> disabled on entry to a subshell.
> 
> There are two ways we could go here:
> 1) Assume that if the user has invoked vared, then it's OK to run ZLE
> even if it was otherwise turned off, and just remove that test
> entirely.  (The check for TERM == emacs is mostly obsolete anyway, if
> we're attempting to do that we should be looking for [absense of]
> certain terminfo values, not a specific terminal type.)
> 2) Figure out some way to remember the old state of USEZLE when
> entering the subshell, and check that in bin_vared instead of checking
> the current state.
[...]

Thanks.

The threads at https://www.zsh.org/mla/workers/2000/msg02518.html and 
http://www.zsh.org/mla/workers/2000/msg02367.html do bring some context.

(for the first one, the threading of messages on the website
seems broken, you can see the other messages in the discussion
at http://www.zsh.org/mla/workers/2000/date3.html)

-- 
Stephane

Re: why can't we use "vared" in a subshell in interactive shells?

[Stephane Chazelas]

2020-02-08 13:23:46 -0800, Bart Schaefer:
> On Sat, Feb 8, 2020 at 11:37 AM Stephane Chazelas <stephane@chazelas.org> wrote:
> >
> > $ (vared -c var)
> > vared: ZLE not enabled
> >
> > Why?
> 
> Looks like an overlooked side-effect to me.  The assumption being made
> is that in interactive mode, if USEZLE is false then it's because the
> user has explicitly unsetopt'd it, not because it was temporarily
> disabled on entry to a subshell.
[...]

The main question here is probably "why is the zle option turned
off in subshells?". AFAICT, zle could only be invoked in
subshells for "vared".

The change (to turn zle off in subshells) is much older (2.5 in
1994).

-- 
Stephane