[erlang-questions] Keeping the break handler for escripts

[Nathaniel Waisbrot]

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. (https://github.com/rebar/rebar3/issues/536)

Looking at the Erlang source code, I saw that the immediate cause of this
is a line in escript.c (
https://github.com/erlang/otp/blob/maint-17/erts/etc/common/escript.c#L458)
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.

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"?

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150627/32e11297/attachment.htm>