pyterm: read space after prompt into prompt #15962
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I've definitely found this annoying, had no idea where it was coming from, just thought of it as a pyterm quirk hahaha :) |
fjmolinas
reviewed
Feb 9, 2021
dist/tools/pyterm/pyterm
Outdated
| @@ -700,6 +710,16 @@ class SerCmd(cmd.Cmd): | |||
| elif c == self.serprompt and output == "": | |||
| sys.stdout.write('%c ' % self.serprompt) | |||
| sys.stdout.flush() | |||
| # we now need to read away the space we printed | |||
There was a problem hiding this comment.
Maybe add a comment above on what is ignored for this whole section?
There was a problem hiding this comment.
The > is not ignored. It is checked in the c == self.serprompt.
There was a problem hiding this comment.
I updated the comment in the latest force push. Is that what you had in mind?
There was a problem hiding this comment.
I don't really understand the wording now TBH
There was a problem hiding this comment.
It's a bit rambling now, but at least it should be easy to understand.
b72f8c0 to
b11bc71
Compare
|
I set up tests to be ran as well :) |
Currently, when the prompt is read in `pyterm` the space after it is ignored for the prompt and the output command just adds its own prompt. This leads to the next output always having a leading space, see e.g. this output from `tests/shell` using `RIOT_TERMINAL=pyterm`: ``` make: Entering directory '/home/mlenders/Repositories/RIOT-OS/RIOT2/tests/shell' /home/mlenders/Repositories/RIOT-OS/RIOT2/dist/tools/pyterm/pyterm -p "/dev/ttyUSB1" -b "500000" Twisted not available, please install it if you want to use pyterm's JSON capabilities 2021-02-09 14:47:15,071 # Connect to serial port /dev/ttyUSB1 Welcome to pyterm! Type '/exit' to exit. bufsize 2021-02-09 14:47:19,712 # bufsize 2021-02-09 14:47:19,712 # 128 > bufsize 2021-02-09 14:47:21,535 # bufsize 2021-02-09 14:47:21,536 # 128 > ``` While this isn't necessarily a problem in most cases, it becomes a problem when the prompt is expected and the output of a command is empty. In that case, the space is added to the empty output, making it " ", so the prompt output command is never triggered and the prompt is added to the next command in the log output. To demonstrate I added a command `empty` to `tests/shell` that just does nothing and deactivated the command echoing using `CFLAGS=-DCONFIG_SHELL_NO_ECHO=1`: ``` empty > empty empty bufsize 2021-02-09 14:54:33,753 # > > 128 > ``` This fixes that problem by also reading the assumed space (we already assume the prompt, so I don't see no harm in that) and if it is not a space to skip the reading of the next char in the next iteration of the reader loop.
533401c to
bd96e4b
Compare
|
Squashed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution description
Currently, when the prompt is read in
pytermthe space after it is ignored for the prompt and the output command just adds its own prompt. This leads to the next output always having a leading space, see e.g. this output fromtests/shellusingRIOT_TERMINAL=pyterm:While this isn't necessarily a problem in most cases, it becomes a problem when the prompt is expected and the output of a command is empty. In that case, the space is added to the empty output, making it " ", so the prompt output command is never triggered and the prompt is added to the next command in the log output. To demonstrate I added a command
emptytotests/shellthat just does nothing and deactivated the command echoing usingCFLAGS=-DCONFIG_SHELL_NO_ECHO=1:This fixes that problem by also reading the assumed space (we already assume the prompt, so I don't see no harm in that) and if it is not a space to skip the reading of the next char in the next iteration of the reader loop.
Testing procedure
Using the provided
emptycommand intests/shellnow yields the expected output:Naturally,
tests/shellshould still pass, when run as testIssues/PRs references
Found in #15951, where a command with empty output lead to problems in the output parsing.