Open khilman opened 4 months ago
Seems like you've additional \x1b[?2004l
and \x1b[?2004h
escape sequences in the output, which seems to be related to bracketed paste mode, so something related to your serial console or OS/shell? Maybe sharing more details about the OS and providing complete YAML config might help track this down.
These are bracketed paste mode sequences, see the note within the ShellDriver documentation.
OK, but the real reason this doesn't match is because labgrid modifies the user-define regex by inserting $MARKER
and \s+
in front of it, thus changing the expected behavior of the user. Isn't the right thing here for labgrid to fix the regex that it prepends to the user-given one to handle the paste mote sequence?
Isn't the right thing here for labgrid to fix the regex that it prepends to the user-given one to handle the paste mode sequence?
For labgrid
to address this, it would need to be aware of the DUT shell's features. This could be managed by probing the shell for its capabilities during runtime (quite cumbersome as there is no termcap entry) or by just introducing a new configuration option in ShellDriver
to handle this?
bracketed_paste_mode (bool, default=False): set to True to enable ShellDriver's awareness that the DUT's
shell uses bracketed paste mode, allowing the shell to differentiate between typed and pasted input.
Related discussion in closed PR https://github.com/labgrid-project/labgrid/pull/975.
Does labgrid really need to know the DUT shell's features? Why not just make the labgrid-inserted regex between $MARKER
and the user-given prompt a little more flexible. Right now it uses \s+
but if that was [\s\W]+
, wouldn't that handle bracketed paste mode?
I'm having problems getting linux shell prompt to match in ShellDriver. This is what have this in config yaml
The default shell prompt on this platform is
root@BeaglePlay:~#
and the initial prompt (copied from the labgrid docs) didn't work, so I tried a more basic match without the regex and it still doesn't match. What am I doing wrong here?In the backtrace below, you can see exactly what's in the pexpect buffer (including the
$MARKER
) and the re.compile expression, but I can't figure out why this isn't matching.