zsh-workers
 help / color / mirror / code / Atom feed
* PATCH: Allow using STTY= to save terminal state
@ 2022-01-18 22:24 Mikael Magnusson
  2022-01-18 22:27 ` Bart Schaefer
  0 siblings, 1 reply; 9+ messages in thread
From: Mikael Magnusson @ 2022-01-18 22:24 UTC (permalink / raw)
  To: zsh-workers

A person in IRC had issues with a command (fastlane) changing some random
stty settings, which broke some stuff (prompt printed twice sometimes
etc). I suggested aliasing fastlane to "STTY=-echonl fastlane" which
causes zsh to restore stty settings after the command returns. However,
it would be nice to be able to do this without having to specify a random
stty setting to actually change when starting the command, this patch
does that.

---
 Src/exec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Src/exec.c b/Src/exec.c
index 63feb6cff6..85e2f8d992 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -684,8 +684,10 @@ execute(LinkList args, int flags, int defpath)
 
     /* If the parameter STTY is set in the command's environment, *
      * we first run the stty command with the value of this       *
-     * parameter as it arguments.                                 */
-    if ((s = STTYval) && isatty(0) && (GETPGRP() == getpid())) {
+     * parameter as it arguments. If the parameter is empty, we   *
+     * do nothing, but this causes the terminal settings to be    *
+     * restored later which can be useful.                        */
+    if ((s = STTYval) && *s && isatty(0) && (GETPGRP() == getpid())) {
 	char *t = tricat("stty", " ", s);
 
 	STTYval = 0;	/* this prevents infinite recursion */
-- 
2.15.1



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: Allow using STTY= to save terminal state
  2022-01-18 22:24 PATCH: Allow using STTY= to save terminal state Mikael Magnusson
@ 2022-01-18 22:27 ` Bart Schaefer
  2022-01-18 23:17   ` Mikael Magnusson
  0 siblings, 1 reply; 9+ messages in thread
From: Bart Schaefer @ 2022-01-18 22:27 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Zsh hackers list

On Tue, Jan 18, 2022 at 2:25 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> A person in IRC had issues with a command (fastlane) changing some random
> stty settings [...]
> it would be nice to be able to do this without having to specify a random
> stty setting to actually change when starting the command

Umm, isn't this what "ttyctl -f" is for?  What have I missed?


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: Allow using STTY= to save terminal state
  2022-01-18 22:27 ` Bart Schaefer
@ 2022-01-18 23:17   ` Mikael Magnusson
  2022-01-19  1:10     ` Bart Schaefer
  2022-01-19 14:06     ` Daniel Shahaf
  0 siblings, 2 replies; 9+ messages in thread
From: Mikael Magnusson @ 2022-01-18 23:17 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Zsh hackers list

On 1/18/22, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Tue, Jan 18, 2022 at 2:25 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>>
>> A person in IRC had issues with a command (fastlane) changing some random
>> stty settings [...]
>> it would be nice to be able to do this without having to specify a random
>> stty setting to actually change when starting the command
>
> Umm, isn't this what "ttyctl -f" is for?  What have I missed?

I remembered about STTY= existing, and its documentation does not
reference ttyctl (in fact nothing references ttyctl except for the
ttyctl entry). That said, running ttyctl -f and ttyctl -u around a
command is a bit more work than simply prepending STTY= (which
currently just causes the stty help text to be printed, which doesn't
seem very useful).

-- 
Mikael Magnusson


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: Allow using STTY= to save terminal state
  2022-01-18 23:17   ` Mikael Magnusson
@ 2022-01-19  1:10     ` Bart Schaefer
  2022-01-19 14:06     ` Daniel Shahaf
  1 sibling, 0 replies; 9+ messages in thread
From: Bart Schaefer @ 2022-01-19  1:10 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Zsh hackers list

On Tue, Jan 18, 2022 at 3:17 PM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> [...] running ttyctl -f and ttyctl -u around a
> command is a bit more work than simply prepending STTY=

The point of ttyctl -f is to run it from .zshrc and only use ttyctl -u
when absolutely necessary.  You're not supposed to need to switch it
on and off.

(I wonder, though, if the thread from users/27471 might get tangled up
here.  Something about the startup sequence seems to have got wonky.)

> ([STTY=]
> currently just causes the stty help text to be printed, which doesn't
> seem very useful).

Agreed that running stty with no arguments in that instance is not helpful.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: Allow using STTY= to save terminal state
  2022-01-18 23:17   ` Mikael Magnusson
  2022-01-19  1:10     ` Bart Schaefer
@ 2022-01-19 14:06     ` Daniel Shahaf
  2022-01-19 17:29       ` Bart Schaefer
  1 sibling, 1 reply; 9+ messages in thread
From: Daniel Shahaf @ 2022-01-19 14:06 UTC (permalink / raw)
  To: Zsh hackers list

Mikael Magnusson wrote on Wed, Jan 19, 2022 at 00:17:10 +0100:
> That said, running ttyctl -f and ttyctl -u around a command is a bit
> more work than simply prepending STTY=

So perhaps we need some syntactic sugar for "wrap a command with
a well-known pair of before/after modifiers".  I'm thinking of something
similar to Python context managers, where
.
    with open("foo.txt") as fd:
        ...
.
is syntactic sugar for
.
    try:
        fd = open("foo.txt")
        ...
    finally: # equivalent to «always» in zsh
        close(fd)
.
.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: Allow using STTY= to save terminal state
  2022-01-19 14:06     ` Daniel Shahaf
@ 2022-01-19 17:29       ` Bart Schaefer
  2022-01-19 20:08         ` Peter Stephenson
  0 siblings, 1 reply; 9+ messages in thread
From: Bart Schaefer @ 2022-01-19 17:29 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

On Wed, Jan 19, 2022 at 6:07 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> So perhaps we need some syntactic sugar for "wrap a command with
> a well-known pair of before/after modifiers".

Not every problem deserves a generalized solution.  This sort of thing
can already be done with function wrappers, wanders pretty far afield
from shell syntax, and adds keywords in ambiguous contexts.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: Allow using STTY= to save terminal state
  2022-01-19 17:29       ` Bart Schaefer
@ 2022-01-19 20:08         ` Peter Stephenson
  2022-01-21  7:11           ` Daniel Shahaf
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Stephenson @ 2022-01-19 20:08 UTC (permalink / raw)
  To: zsh-workers

On Wed, 2022-01-19 at 09:29 -0800, Bart Schaefer wrote:
> On Wed, Jan 19, 2022 at 6:07 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > 
> > So perhaps we need some syntactic sugar for "wrap a command with
> > a well-known pair of before/after modifiers".
> 
> Not every problem deserves a generalized solution.  This sort of thing
> can already be done with function wrappers, wanders pretty far afield
> from shell syntax, and adds keywords in ambiguous contexts.

Yes, I think Mikael's tiny change would be a good addition.
The STTY parameter is not something crying out for generalisation.

pws




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: Allow using STTY= to save terminal state
  2022-01-19 20:08         ` Peter Stephenson
@ 2022-01-21  7:11           ` Daniel Shahaf
  2022-01-22 22:44             ` Bart Schaefer
  0 siblings, 1 reply; 9+ messages in thread
From: Daniel Shahaf @ 2022-01-21  7:11 UTC (permalink / raw)
  To: zsh-workers

Peter Stephenson wrote on Wed, 19 Jan 2022 20:08 +00:00:
> On Wed, 2022-01-19 at 09:29 -0800, Bart Schaefer wrote:
>> On Wed, Jan 19, 2022 at 6:07 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>> > 
>> > So perhaps we need some syntactic sugar for "wrap a command with
>> > a well-known pair of before/after modifiers".
>> 
>> Not every problem deserves a generalized solution.  This sort of thing
>> can already be done with function wrappers, wanders pretty far afield
>> from shell syntax, and adds keywords in ambiguous contexts.
>
> Yes, I think Mikael's tiny change would be a good addition.
> The STTY parameter is not something crying out for generalisation.

Fair enough.

As to "adds keywords in ambiguous contexts": I haven't proposed any
particular syntax; I only described functionality.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: PATCH: Allow using STTY= to save terminal state
  2022-01-21  7:11           ` Daniel Shahaf
@ 2022-01-22 22:44             ` Bart Schaefer
  0 siblings, 0 replies; 9+ messages in thread
From: Bart Schaefer @ 2022-01-22 22:44 UTC (permalink / raw)
  To: Zsh hackers list

On Thu, Jan 20, 2022 at 11:12 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> As to "adds keywords in ambiguous contexts": I haven't proposed any
> particular syntax; I only described functionality.

Fair enough. :-)  I'm not sure how you'd do it without a keyword, though.

As to the original question, zsh runs "stty" without qualification, so
you can do:

stty() {
  [[ -n "$*" ]] && command stty "$@"
}

to get the same effect as Mikael's patch.


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-01-22 22:44 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-18 22:24 PATCH: Allow using STTY= to save terminal state Mikael Magnusson
2022-01-18 22:27 ` Bart Schaefer
2022-01-18 23:17   ` Mikael Magnusson
2022-01-19  1:10     ` Bart Schaefer
2022-01-19 14:06     ` Daniel Shahaf
2022-01-19 17:29       ` Bart Schaefer
2022-01-19 20:08         ` Peter Stephenson
2022-01-21  7:11           ` Daniel Shahaf
2022-01-22 22:44             ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).