stty not working

stty not working

[Сергей Новиков]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

Hi,
I am trying to unset ECHO flag for tty, but stty doesn't work. After
reading documentation I am still not clear about its behavior.
> ttyctl
> tty is not frozen
> stty -echo
> test test
but
> stty -echo; read <enter>
working fine. My brain is broken.
With best regards.

Re: stty not working

[Bart Schaefer]

On Sep 1,  6:38am, 0x04210x04350x04400x04330x04350x0439 0x041D0x043E0 wrote:
}
} I am trying to unset ECHO flag for tty, but stty doesn't work. After
} reading documentation I am still not clear about its behavior.

If you "unsetopt ZLE" to turn off the line editor, your "stty -echo"
will stick.  ZLE can't operate with echo turned off, so it turns it
back on again.

} but
} > stty -echo; read <enter>
} working fine. My brain is broken.

During execution of a command line such as that, the stty change takes
effect and remains in effect until ZLE re-initializes (approximately
until the next prompt is displayed).

Re: stty not working

[Mikael Magnusson]

On 1 September 2014 04:38, Сергей Новиков <arrecck@gmail.com> wrote:
> Hi,
> I am trying to unset ECHO flag for tty, but stty doesn't work. After
> reading documentation I am still not clear about its behavior.
>> ttyctl
>> tty is not frozen
>> stty -echo
>> test test
> but
>> stty -echo; read <enter>
> working fine. My brain is broken.
> With best regards.

You can do this too,
STTY=-echo cat
and zsh will set -echo for the duration of that command. Since read is
a builtin it doesn't work for that, but it has a flag to turn off
echoing already.

-- 
Mikael Magnusson

Re: stty not working

[Peter Stephenson]

Maybe we should be a bit more explicit about what ttyctl does and
doesn't do.  ("tty" seems a bit archaic --- I think it's thirty years
since I've seen anything resembling a teletype --- so I added an
explanation.)  For example:

diff --git a/Doc/Zsh/builtins.yo b/Doc/Zsh/builtins.yo
index f709f50..c23b0e4 100644
--- a/Doc/Zsh/builtins.yo
+++ b/Doc/Zsh/builtins.yo
@@ -1639,7 +1639,8 @@ Do nothing and return an exit status of 0.
 findex(ttyctl)
 cindex(tty, freezing)
 item(tt(ttyctl) tt(-fu))(
-The tt(-f) option freezes the tty, and tt(-u) unfreezes it.
+The tt(-f) option freezes the tty (i.e. terminal or terminal emulator), and
+tt(-u) unfreezes it.
 When the tty is frozen, no changes made to the tty settings by
 external programs will be honored by the shell, except for changes in the
 size of the screen; the shell will
@@ -1647,6 +1648,14 @@ simply reset the settings to their previous values as soon as each
 command exits or is suspended.  Thus, tt(stty) and similar programs have
 no effect when the tty is frozen.  Without options it reports whether the
 terminal is frozen or not.
+
+Note that, regardless of whether the tty is frozen or not, the
+shell needs to change the settings when the line editor starts, so
+unfreezing the tty does not guarantee settings made on the
+command line are preserved.  Strings of commands run between
+editing the command line will see a consistent tty state.
+See also the shell variable tt(STTY) for a means of initialising
+the tty before running external commands.
 )
 findex(type)
 item(tt(type) [ tt(-wfpams) ] var(name) ...)(

Re: stty not working

[Bart Schaefer]

On Sep 1, 11:16am, Peter Stephenson wrote:
} Subject: Re: stty not working
}
} Maybe we should be a bit more explicit about what ttyctl does and
} doesn't do.

ttyctl also doesn't "remember" the external stty state for assertion
when the line editor finishes.  E.g., I might have expected that

% ttyctl -u; stty -echo; ttyctl -f

would "freeze" the terminal in no-echo mode, such that when accept-line
is run and ZLE finishes, the terminal would be put into no-echo mode
before the command is run.  But that's not what happens; "freeze" does
not mean to lock the current state, it means to *block* changes made
by subsequent commands.  Which is what the doc says, but perhaps not
clearly enough.

Re: stty not working

[Peter Stephenson]

I ended up with this.

diff --git a/Doc/Zsh/builtins.yo b/Doc/Zsh/builtins.yo
index f709f50..9862c63 100644
--- a/Doc/Zsh/builtins.yo
+++ b/Doc/Zsh/builtins.yo
@@ -1639,14 +1639,26 @@ Do nothing and return an exit status of 0.
 findex(ttyctl)
 cindex(tty, freezing)
 item(tt(ttyctl) tt(-fu))(
-The tt(-f) option freezes the tty, and tt(-u) unfreezes it.
+The tt(-f) option freezes the tty (i.e. terminal or terminal emulator), and
+tt(-u) unfreezes it.
 When the tty is frozen, no changes made to the tty settings by
 external programs will be honored by the shell, except for changes in the
 size of the screen; the shell will
 simply reset the settings to their previous values as soon as each
 command exits or is suspended.  Thus, tt(stty) and similar programs have
-no effect when the tty is frozen.  Without options it reports whether the
-terminal is frozen or not.
+no effect when the tty is frozen.  Freezing the tty does not cause
+the current state to be remembered: instead, it causes future changes
+to the state to be blocked.
+
+Without options it reports whether the terminal is frozen or not.
+
+Note that, regardless of whether the tty is frozen or not, the
+shell needs to change the settings when the line editor starts, so
+unfreezing the tty does not guarantee settings made on the
+command line are preserved.  Strings of commands run between
+editing the command line will see a consistent tty state.
+See also the shell variable tt(STTY) for a means of initialising
+the tty before running external commands.
 )
 findex(type)
 item(tt(type) [ tt(-wfpams) ] var(name) ...)(

pws

Re: stty not working

[Peter Stephenson]

On Mon, 01 Sep 2014 11:28:37 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> E.g., I might have expected that
> 
> % ttyctl -u; stty -echo; ttyctl -f
> 
> would "freeze" the terminal in no-echo mode, such that when accept-line
> is run and ZLE finishes, the terminal would be put into no-echo mode
> before the command is run.

It's very simple to add an option to ttyctl that saves the current state
of the terminal.  However, when we enter zle we call zsetterm() --- I
think typically in zrefresh() though the logic for setting up the
terminal seems a bit obscure --- which does...

    /* sanitize the tty */
    shttyinfo.tio.c_lflag |= ICANON | ECHO;

It's not entirely clear to me we should be doing that: the rest of
zsetterm() assigns shttyinfo to a local variable and then proceeds to
set up for line editing using operations on that, so they don't get
applied to the terminal settings used outside zle.  So maybe this ought
to do the same thing and we rely on the user knowing what they're doing
outside zle.

I haven't checked if this is the only gotcha.

pws

Re: stty not working

[Bart Schaefer]

On Sep 2,  2:26pm, Peter Stephenson wrote:
}
} [...] However, when we enter zle we call zsetterm() --- I
} think typically in zrefresh() though the logic for setting up the
} terminal seems a bit obscure --- which does...
} 
}     /* sanitize the tty */
}     shttyinfo.tio.c_lflag |= ICANON | ECHO;
} 
} It's not entirely clear to me we should be doing that: the rest of
} zsetterm() assigns shttyinfo to a local variable and then proceeds to
} set up for line editing using operations on that

Yes, but it appears that user-defined widgets and completion use the
global shttyinfo to re-sanitize any time there's an opportunity for
an external command to have changed something.

So we'd at least need another zle global for this.  I don't think it's
commonly enough needed to justify the change; the question that started
this thread was resolved by "unsetopt zle".

Re: stty not working

[Peter Stephenson]

On Tue, 02 Sep 2014 08:52:30 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Sep 2,  2:26pm, Peter Stephenson wrote:
> }
> } [...] However, when we enter zle we call zsetterm() --- I
> } think typically in zrefresh() though the logic for setting up the
> } terminal seems a bit obscure --- which does...
> } 
> }     /* sanitize the tty */
> }     shttyinfo.tio.c_lflag |= ICANON | ECHO;
> } 
> } It's not entirely clear to me we should be doing that: the rest of
> } zsetterm() assigns shttyinfo to a local variable and then proceeds to
> } set up for line editing using operations on that
> 
> Yes, but it appears that user-defined widgets and completion use the
> global shttyinfo to re-sanitize any time there's an opportunity for
> an external command to have changed something.

The point here is that you *do* want the external command to change it
--- but maybe only sometimes.

> So we'd at least need another zle global for this.  I don't think it's
> commonly enough needed to justify the change; the question that started
> this thread was resolved by "unsetopt zle".

I certainly agree it's not important enough to break anything, but I'm
not entirely sure another global makes sense anyway --- when would you
use it that you didn't instead use the existing one?  You'd effectively
have a three-way switch --- zle mode, sane mode, user-defined mode ---
and defining the way the switch works is going to be difficult,
particularly given the fairly ill-defined way the effective two-way
switch plus additional sanity works at the moment.

As long as no one really expects ttyctl to save the state we can drop
this.

pws

Re: stty not working

[Bart Schaefer]

On Sep 2,  5:04pm, Peter Stephenson wrote:
}
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Yes, but it appears that user-defined widgets and completion use the
} > global shttyinfo to re-sanitize any time there's an opportunity for
} > an external command to have changed something.
} 
} The point here is that you *do* want the external command to change it
} --- but maybe only sometimes.

Certainly, but I don't think the middle of a completion is one of the
times we'd want to allow it to change?

} > So we'd at least need another zle global for this.
} 
} not entirely sure another global makes sense anyway --- when would you
} use it that you didn't instead use the existing one? You'd effectively
} have a three-way switch --- zle mode, sane mode, user-defined mode ---
} and defining the way the switch works is going to be difficult

I think there'd still only be two modes, sane and user-defined.  There
isn't any reason I can think of for sane and zle to be distinct.  But
right now we store only sane mode in the global, so to make this work
we'd need to remember user-defined mode as well.

} As long as no one really expects ttyctl to save the state we can drop
} this.

Yeah, sorry, this horse is pining for the fjords.