<div dir="ltr"><div><div><div><div>When running an escript on a Unix system, interrupting with control-c leaved the terminal in a messy state (mostly that newlines don't trigger line-feeds). This is most visible when using Rebar with the "shell" command. (<a href="https://github.com/rebar/rebar3/issues/536">https://github.com/rebar/rebar3/issues/536</a>)<br><br></div>Looking at the Erlang source code, I saw that the immediate cause of this is a line in escript.c (<a href="https://github.com/erlang/otp/blob/maint-17/erts/etc/common/escript.c#L458">https://github.com/erlang/otp/blob/maint-17/erts/etc/common/escript.c#L458</a>) that adds the "+B" emulator flag to all escript runs. "+B" (equivalent to "+Bd") disables the interrupt handler, which is both responsible for bringing up the "BREAK: (a)bort (c)ontinue..." menu, as well as for calling sys_tty_reset to put the TTY back the way it was before erl started.<br><br></div>So my first question is, is the "+B" flag needed on escripts at all? It seems to me that between screwing up the TTY or popping up a useless menu (useless because we might be in a shell pipeline and unable to respond to the prompt), the menu is the better option. Are there things that would actually be broken by removing "+B"?<br><br></div>Second, if "+B" can't be removed, would it be reasonable to make "+B" reset the TTY without showing the menu? Essentially have two break handlers, and "+B" would get you the lesser handler, rather than none at all.<br><br></div>Finally, if that's also a bad option, what about providing a "+Be" flag to re-enable the disabled break handler? So escripts that knew that they were going to be long-running or user-interactive could specify +Be on their emulator arguments to undo the +B default.<br></div>