Slow startup on macOS with bash and intr=^G

[egmontkob]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

GNU Midnight Commander 4.8.33-353-gc57edfe67
Built with GLib 2.80.4 (using GLib 2.80.4)
Built with NCurses 5.7.20081102 (using ncurses 5.7.20081102)
Built with libssh2 1.11.0
With builtin editor
With subshell support as default
With support for background operations
With mouse support on xterm
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, shell
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; uintmax_t: 64;

Operating system

Darwin Kernel Version 21.6.0 [...] root:xnu-8020.140.49~2/RELEASE_ARM64_T8101 arm64

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

• macOS
• bash 3.2 as shell
• stty intr ^G

Start up mc, observe delay.

Expected behavior

No delay.

Actual behavior

About 10 seconds of delay.

Additional context

Issue is present both without and with the patches from #4625.

Cannot reproduce on Linux. Cannot reproduce with the default stty intr ^C. Cannot reproduce with zsh if the patches from 4625 are applied.

On macOS, killing mc (which I had to do a lot while debugging 4625 / 4780) leaves the terminal in a dirty state, including the interrupt character being ^G.

The command reset (on both platforms) leaves the interrupt character unchanged. On macOS it prints "Interrupt is control-G (^G)" but this might be somewhat misleading: it did not set this value newly, it just observed and warned about this unusual nondefault value.

Two questions:

• Why does mc leave the terminal with this setting? Is it an mc bug or weird circumstance that we should fix?
• Why does mc have a startup delay with this setting?

[egmontkob]

mc does sometimes send the hardcoded byte 0x03 (Ctrl-C) with the intent that it will interrupt whatever's happening inside. 4625's first patch is relevant here.

We could make it dynamic: query the stty settings and send that byte. Or we could say that anything other than ^C is unsupported; still, we could maybe check that on startup and warn the user.

Or just not copy this setting from the outer terminal to the inner one: instead, set the inner one's to Ctrl-C. Would this work?

[ossilator]

as an alternative to letting the tty layer handle it, we could just send SIGINT to the shell's process group directly.

but as i noted in the other issue, the ideal outcome would be avoiding the situations where we need to interrupt the shell for synchronization in the first place. maybe that's not realistic, but maybe the circumstances can be fully documented?

[egmontkob]

mc itself sets the outer tty to ^G, at lib/tty/tty-ncurses.c (and only there):

    // use Ctrl-g to generate SIGINT
    mode.c_cc[VINTR] = CTRL ('g');  // ^g

So I guess it's not macOS vs. Linux, it's ncurses vs. slang. (And indeed, my macOS build uses ncurses, and on Linux I use slang.)

This behavior dates back to #1876 / a20ebb3. Gotta read that ticket to learn why it's really needed.

[egmontkob]

as an alternative to letting the tty layer handle it, we could just send SIGINT to the shell's process group directly.

I think (but this might vary case by case) we have double goal here: to flush the input, as well as send the signal. Manually sending SIGINT would do half of that story, and a tcflush() could do the other half. So yes it's indeed something we might consider doing.

the ideal outcome would be avoiding [...]

It's sure lot of technical debt and magical hacks. Not sure how much it's actually possible or worth it to clean up.

[egmontkob]

So, mc's outer tty (with ncurses) is set to ^G, but the inner one is still on ^C. This is a change the user shouldn't see, the user should never need to press Ctrl+G instead of Ctrl+C.

Note: stty (somewhat surprisingly) works on its stdin (this is so that you can redirect its output/error to a file), so the easiest way to query the terminal's setting while mc is running is to run stty < /dev/... from another terminal. [EDIT: as it later turned out, it's only true for coreutils, not for rust uutils.]

Things obviously go wrong if you kill mc. Maybe it could have a handler for softer signals that restore the terminal before exiting. (Still wouldn't restore on SIGKILL, obviously.)

Anyway, the behavior after the software is killed, let alone given that reset doesn't properly reset the terminal either, is IMHO quite low priority. I just happened to hit it during debugging, users shouldn't hit this issue too often.

[ossilator]

well, actually, i have to use reset to clean up after a crashed mc rather often ... each time an ssh session dies. i build with slang, and usually i restart ssh+mc immediately afterwards anyway, so the issue is somewhat academical for me. but it shouldn't be dismissed entirely, so if we can get rid of it at reasonable cost, it's a thing to consider.

[mc-worker]

mc itself sets the outer tty to ^G, at lib/tty/tty-ncurses.c (and only there):

The same is done in lib/tty/tty-slang.c:

 SLang_init_tty (XCTRL ('g'), 1, 0);

[egmontkob]

each time an ssh session dies

There ssh itself is another layer of protection. It doesn't forward changes of the stty settings to the host terminal, so that's still left on ^C when the connection breaks.

if we can get rid of it at reasonable cost, it's a thing to consider

Either forcing ^C in the inner terminal (rather than copying the outer one's settings), or altering the sent byte to whatever the interrupt character is (rather than 0x03) sounds pretty low hanging fruit.

The second one sounds better to me: If the user, for whatever mysterious reason, prefers ^G or any other key, we should respect that rather than override. With the addition that if it's undefined then set it to ^C.

---

Also, let's study that change of #1876. Allegedly Ctrl+C interrupts (or used to interrupt) mcedit, so the interrupt byte was moved to ^G. But then wouldn't ^G interrupt the editor??

I've removed that one line I've mentioned above (with VINTR), and confirm from another terminal that the host terminal's settings are no longer switched to ^G (macOS, ncurses). That means that after killing mc, this aspect of the terminal line is clean, and the next mc will start up correctly. Pressing ^C in the internal editor, either invoked from mc with F4, or with mc -e doesn't seem to do anything, doesn't kill the editor.

So, do we need that ^G setting? I don't think so.

---

PS. Just this morning I've upgraded with Ubuntu 25.10 with its Rust replacement for coreutils (including stty), and its absolutely useless zero manual page not describing any of the parameters. I'm already hating it.

[mc-worker]

the user should never need to press Ctrl+G instead of Ctrl+C.

User could want to bind Ctrl-C key to copy a text to buffer.

[egmontkob]

User could want to bind Ctrl-C key to copy a text to buffer.

Could you please elaborate; what context are we in? The editor?

Shouldn't the user be able to bind Ctrl-G to whatever they want to? Is there always necessarily a character that is unbindable?

The last question in 1876 by ossi was: "why do you assign any key for sigint at all?" We could set intr to undef, or -isig to disable all signals. Or, internally, we can assign the signal to any behavior (e.g. copying to a text buffer) although that's arguably ugly design.

[egmontkob]

The same is done in lib/tty/tty-slang.c:

SLang_init_tty (XCTRL ('g'), 1, 0);

Interestingly, on my slang build on Linux, the outer line remains on ^C. So I guess this slang method does something different.