Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
subsys: shell rework #9362
We have changed commands concept.
On one command level all commands must be the same type: static or dynamic.
requested review from
Aug 9, 2018
@@ Coverage Diff @@ ## master #9362 +/- ## ========================================== - Coverage 52.94% 52.18% -0.77% ========================================== Files 214 212 -2 Lines 26163 25924 -239 Branches 5639 5570 -69 ========================================== - Hits 13853 13528 -325 - Misses 10037 10133 +96 + Partials 2273 2263 -10
Great work. I like the dynamic command sample. Some minor comments from me.
referenced this pull request
Aug 9, 2018
@nashif thank you for checking it :)
In order to make backspace work (in PuTTY) you need to change terminal settings:
Now we will work to make tests green :)
@nashif I have reproduced the issue with "screen" application.
@pfalcon this is what I did. In standard Linux shell you have possibility to use Backspace and Delete buttons and they realize different functions :).
Old shell implementation assumes that Backspace and Delete are sending the same escape code so you have no possibility to realize different functions for them.
There are many terminals and each is behaving in different way. For instance "minicom" is working correctly out of the box: Backspace and Delete are sending different (and correct) escape codes.
Screen out of the box is sending the same escape code for Backspace and Delete button (incorrect behaviour). To fix the Screen application you need to do what I've proposed.
In my opinion the best solution is to combine point 2 and 3. I can implement a command to configure shell in the "old mode" where Backspace and Delete are not distinguished.
@jarz-nordic: Ok, thanks for the detailed reply. I hope to give it a try with "picocom" I use (and that's part of the issue - everyone uses their own favorite terminal app, so the shell should "work with any of them", which entails working "as any other app working over serial".) Btw, while an individual terminal app may of course do adhoc processing, I'd assume that overall the key codes they send would be governed by system-wide termcap/terminfo database.