Allow enabling flow control also inside the shell

[depau]

• fish, version 3.1.2
• Linux frigo 5.10.9-arch1-1 Need a history built-in #1 SMP PREEMPT Tue, 19 Jan 2021 22:06:06 +0000 x86_64 GNU/Linux
• sh -c 'env HOME=$(mktemp -d) fish' - yep, it still does it

When running on a serial console which I explicitly configured with ixon and ixoff, fish keeps disabling said options every time a new prompt is printed.

I understand that users might think their system is locked up if they press Ctrl+S by mistake and the terminal stops responding, however there are cases in which one may need software flow control.

Is it possible to disable this behavior?

Reproducing

• Run fish in one terminal
• Run tty to find the tty/pty it's attached to
• In another terminal, run sudo stty -F <tty found above> ixon ixoff to enable software flow control
• Run sudo stty -a -F <tty found above> to verify that ixon and ixoff have indeed been enabled
• Go back to the initial fish terminal and press enter
• Run sudo stty -a -F <tty found above> to verify that ixon and ixoff have been disabled by fish
• Do the same thing with another shell, such as bash, to verify that it respects the user's decision

(using another terminal makes it easier to demonstrate the issue since otherwise fish resets the terminal right after stty is run)

(to whoever thought "who uses software flow control intentionally in 2021 anyway?", I do 😜)

[faho]

Duplicate of #2315

[faho]

Short answer: The next release will sanitize the terminal modes instead of just resetting them all, this allows you to enable flow control. It remains off by default.

[depau]

(replying here because the other issue is locked)

Seeing that 3.2.0 looks close to being released according to the number of open issues in the GH milestone, I tested this on the latest git (2bab31a as I'm writing this) and it still disables ixon/ixoff, even if I set them before starting fish.

I see that it does restore the terminal to how it found it on exit, however my application needs flow control enabled *while* fish is running.

Does the new behavior you mentioned need to be enabled explicitly?

[faho]

I see that it does restore the terminal to how it found it on exit, however my application needs flow control enabled while fish is running.

Ah, okay. Yeah, that's not supported.

Like I said, fish sanitizes the modes still, and flow control doesn't seem very useful inside the shell - it's already waiting for input, why do you want it stopped?

What are you using this for?

[depau]

What are you using this for?

First of all, I'm sorry 😂 I know this is a very niche use-case.

I'm porting ttyd (https://github.com/tsl0922/ttyd/) to ESP8266. It My port exposes the UART console over WebSockets, with the use-case being having a cheap device that can be plugged into an SBC for remote debugging of boot and network connection issues, one that doesn't force you to shut down the device and move it somewhere more comfortable to work on with a USB UART adapter.

One of my goals is supporting relatively high baud rates such as 1500000, which is the default on many RockChip-based platforms.

It works fine for the most part, however with bulky streams of data (such as zmodem, s-tui or... nyancat) the transmission is bottlenecked by Wi-Fi/TCP - while the 802.11n rate is technically higher than 1500000bps it's still an ESP8266. The result is that when the WebSocket frame queue is full, some frames are dropped and the terminal gets garbled (or the zmodem transfer breaks).

This is very reliably solved with flow control - when the queue is full I keep buffering the incoming data from UART and send XOFF, then send XON when the internal UART buffer is almost empty.

Normal, low-bandwidth shell usage is fine, with or without fish and with or without flow control. However even ls-ing a huge directory or dumping the kernel log without flow control can easily fill up the WS queue at high baud rates.

[ridiculousfish]

Flow control was initially disabled in #814. FWIW zsh supports this with setopt noflowcontrol.

For the case of ls or cat, then in fish 3.2 you can use stty ixon to enable flow control and it will stick. Maybe we should stop defaulting flow control off for external commands. Would that address this issue?

[faho]

As I read it, the problem is that you don't know what is currently in control of the terminal when you have to make it slow down to catch up, so this does indeed need fish to stop as well.

Maybe we should stop defaulting flow control off for external commands.

Flow control is a horrible default, and if this needs it to stick for fish as well, that won't help.

How about we just turn off flow control on start (especially as we have important bindings for ctrl-s) and keep whatever setting comes later, i.e. copy it to the shell-modes from whatever modes the command ends with?

[depau]

As I read it, the problem is that you don't know what is currently in control of the terminal when you have to make it slow down to catch up, so this does indeed need fish to stop as well.

Yes, exactly. ttyd does not have this issue since it uses pseudo-terminals: for what it's worth it can just stop reading and the pty driver will do its job. UART however needs the device on the other end to ask nicely.

Maybe we should stop defaulting flow control off for external commands.

Flow control is a horrible default, and if this needs it to stick for fish as well, that won't help.

How about we just turn off flow control on start (especially as we have important bindings for ctrl-s) and keep whatever setting comes later, i.e. copy it to the shell-modes from whatever modes the command ends with?

I was going to say the following:

The best option for me would be to just leave the flow control settings alone until a configuration option is read: fish doesn't change anything on start, then it verifies that some config variable is or is not present and decides how to behave from then on.

But then I realized that fish doesn't print anything until config.fish is read, so your solution works too. I could check what fish is attached to in config.fish and stty if it's a UART tty.

Overall, for my use-case, anything works as long as while fish is running it uses flow control settings that the user can configure, and as long as the implemented solution doesn't cause it to write to the terminal before ensuring the user hasn't configured different terminal settings.

[depau]

as long as the implemented solution doesn't cause it to write to the terminal before ensuring the user hasn't configured different terminal settings.

I mean, if I can add something like this to the beginning of config.fish, it works for me:

string match -rq '/dev/tty[A-Za-z]+\d*' (tty) && stty ixon ixoff

[zanchey]

FWIW (I think we should implement these changes anyway) when I was doing serial stuff many moons ago, we found hardware flow control to be a lot more reliable than software flow control. We did have a fair bit of control over the hardware being used though, including wiring our own cables a lot of the time.