[riot-notifications] [RIOT-OS/RIOT] sys/shell: Exit the shell on ctrl-D or ctrl-C. (#10788)
Juan I Carrano
notifications at github.com
Thu Jan 17 12:26:10 CET 2019
> This still leaves the node in an "unexpected" state. If I reconnect with a terminal I expect the node still to do whatever it was doing before
It will. You can try it out. If CTRL-C exits the `TERMPROG`, it means that `TERMPROG` caught it and it was __not__ sent to the node, and the shell never exited.
Exiting the shell allows one to write a test like the one in #9733 where the first part is interactive, then the shell exits and a non interactive part is run. Of course, the non interactive part can be first, but then the test starts immediately after the node boots, and we know this brings synchronization issues.
Also, if the shell can exit, but one does not want it to, it is easy to fix (wrap it in a while loop). The other case (it does not exit, but one wants it to) is not.
Observe that the shell _can_ be exited now, so this is not adding the possibility of exiting, just another way to do it:
Lastly: _why the shell needs not to exit?_ I honestly don't understand why we are bikeshedding a <1 line change. Look at the asymmetry between the reliance we have on the shell (especially for tests) and the quality of the module and associated tools (like pyterm.) I'm doing a series of PRs trying to improve the situation (#10630, #10635, #9733) and I have other PRs on the works and I keep running into the same endless bikeshedding. Look at this change: it add 74 lines of code: one is the change itself, the remaining 73 are tests: tests that test all, and that run without interaction. I cannot help but wonder why the long discussion, when stuff with much less testing and more poorly described gets in way more easily.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications