Inquire leaves the terminal in a broken state

[msrd0]

Describe the bug

When you kill a program that currently has an open inquire prompt, i.e. nicely ask the program to shut down, inquire does not properly clean up after itself. Instead, the terminal is left in a bad state where it does not echo back commands and my prompts are randomly indented by a tab or so. Typing reset of course fixes this but is something I should not have to do manually.

Desktop (please complete the following information):

• OS: I use Arch btw
• Browser: tf?????
• Version: 0.6.2

[mikaelmello]

• OS: I use Arch btw
• Browser: tf?????
• Version: 0.6.2

lol, I guess I never paid attention to the bug report template

---

handling sigterm is a tricky thing in and of itself, and I honestly have no idea on which role inquire should take, being a library

do you have any ideas in mind? or better yet, references on how other libs solve this issue?

one of the options would be to add signal handling behind a feature, and those interested in it can opt-in on the additional dependency, but then again, tricky :)

[msrd0]

Hm well I foolishly assumed that sigterm is handled nicely by rust by default, i.e. that it runs stuff like Drop impls and then exits. But apparently it does not run Drop impls but just exits right away. So I guess you'll either want to expose a feature flag that makes inquire set up a signal handler, or expose a function that needs to actively be called by the user of the library that will then register the signal handler.

do you have any ideas in mind? or better yet, references on how other libs solve this issue?

I think tokio does it quite nicely - they seem to register some form of signal handler that just stores the received signals for the application to process. At least thats how I interpret their documentation: https://docs.rs/tokio/latest/tokio/signal/index.html. The best way would probably be to have something like this as part of std so that all applications and libraries share that api instead of doing it their way, but I guess that's not a reality right now.

[mikaelmello]

Yeah, one thing I've realized with this crate is there are two conflicting goals here, either make it simple and lean or a highly customizable thing that tries to support all scenarios.

Adding a signal handler is more of the latter, and I have been seriously wondering if inquire is accumulating a lot of bloat (e.g. see the Text prompt), and is missing the initial goal of simple prompts

From my own experience, cli apps breaking on unexpected events (resizing, signals) is often the norm, so I'm wondering how much a new feature to handle sigterm would actually be used. Because then I'll have to start adding some inter thread communication, change some lifecycle things, etc