elvish icon indicating copy to clipboard operation
elvish copied to clipboard

Terminal interrupts should not fall through "try" and "?(...)"

Open hanche opened this issue 5 years ago • 1 comments

Example (pardon my non-standard prompt and value-out-indicator):

⬥ try { read-upto "\n" } finally { put done }
^C
⮕ "\n"
Exception: interrupted
[tty], line 1: try { read-upto "\n" } finally { put done }
⬥

In this example, the builtin command read-upto does manage to capture the interrupt, finish its work, and re-throw the error. But the try construct fails to run the cleanup code. The same happens when it executes an external command, such as sleep 10.

Perhaps this is by design: If terminal interrupts can be captured, a tryexcept inside a loop could lead to a situation from which there is no escape. However, even if so, I think at least the finally block should be allowed to run.

The scenario I had in mind, is this:

pw=(try { stty -echo; print 'password: ' >/dev/tty; read-upto "\n" } finally { stty echo })

where it is important that the cleanup action is run no matter what.

hanche avatar Apr 02 '20 12:04 hanche

This is indeed a bug, and it has something to do with how terminal interrupts are relayed to Elvish functions.

Aiming to fix this before 0.14.

xiaq avatar Apr 17 '20 21:04 xiaq