[PATCH] test: Make handling of shell prompts with escapes a little more reliable
When using the old-style "pane" methods of executing commands during the
tests, we need to scan the shell output for prompts in order to tell when
commands have finished. This is inherently unreliable because commands
could output things that look like prompts, and prompts might not look like
we expect them to. The only way to really fix this is to use a better way
of dispatching commands, like the newer "context" system.
However, it's awkward to convert everything to "context" right at the
moment, so we're still relying on some tests that do work most of the time.
It is, however, particularly sensitive to fancy coloured prompts using
escape sequences. Currently we try to handle this by stripping actual
ESC characters with tr, then looking for some common variants.
We can do a bit better: instead strip all escape sequences using sed before
looking for our prompt. Or, at least, any one using [a-zA-Z] as the
terminating character. Strictly speaking ANSI escapes can be terminated by
any character in 0x40..0x7e, which isn't easily expressed in a regexp.
This should capture all common ones, though.
With this transformation we can simplify the list of patterns we then look
for as a prompt, removing some redundant variants.
Signed-off-by: David Gibson
On Thu, 23 Nov 2023 12:52:53 +1100
David Gibson
When using the old-style "pane" methods of executing commands during the tests, we need to scan the shell output for prompts in order to tell when commands have finished. This is inherently unreliable because commands could output things that look like prompts, and prompts might not look like we expect them to. The only way to really fix this is to use a better way of dispatching commands, like the newer "context" system.
However, it's awkward to convert everything to "context" right at the moment, so we're still relying on some tests that do work most of the time. It is, however, particularly sensitive to fancy coloured prompts using escape sequences. Currently we try to handle this by stripping actual ESC characters with tr, then looking for some common variants.
We can do a bit better: instead strip all escape sequences using sed before looking for our prompt. Or, at least, any one using [a-zA-Z] as the terminating character. Strictly speaking ANSI escapes can be terminated by any character in 0x40..0x7e, which isn't easily expressed in a regexp. This should capture all common ones, though.
With this transformation we can simplify the list of patterns we then look for as a prompt, removing some redundant variants.
Signed-off-by: David Gibson
I didn't forget about this one, but I had unrelated test failures which I wasn't sure about. This is actually fine though. Applying soon. -- Stefano
On Mon, Dec 04, 2023 at 10:54:33AM +0100, Stefano Brivio wrote:
On Thu, 23 Nov 2023 12:52:53 +1100 David Gibson
wrote: When using the old-style "pane" methods of executing commands during the tests, we need to scan the shell output for prompts in order to tell when commands have finished. This is inherently unreliable because commands could output things that look like prompts, and prompts might not look like we expect them to. The only way to really fix this is to use a better way of dispatching commands, like the newer "context" system.
However, it's awkward to convert everything to "context" right at the moment, so we're still relying on some tests that do work most of the time. It is, however, particularly sensitive to fancy coloured prompts using escape sequences. Currently we try to handle this by stripping actual ESC characters with tr, then looking for some common variants.
We can do a bit better: instead strip all escape sequences using sed before looking for our prompt. Or, at least, any one using [a-zA-Z] as the terminating character. Strictly speaking ANSI escapes can be terminated by any character in 0x40..0x7e, which isn't easily expressed in a regexp. This should capture all common ones, though.
With this transformation we can simplify the list of patterns we then look for as a prompt, removing some redundant variants.
Signed-off-by: David Gibson
I didn't forget about this one, but I had unrelated test failures which I wasn't sure about. This is actually fine though. Applying soon.
I don't think there's any particular need to make a release for it, but it would be nice to get this in the main git tree, so I don't have to keep awkwardly carrying it about to test my other branches. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On Thu, 7 Dec 2023 12:09:26 +1100
David Gibson
On Mon, Dec 04, 2023 at 10:54:33AM +0100, Stefano Brivio wrote:
On Thu, 23 Nov 2023 12:52:53 +1100 David Gibson
wrote: When using the old-style "pane" methods of executing commands during the tests, we need to scan the shell output for prompts in order to tell when commands have finished. This is inherently unreliable because commands could output things that look like prompts, and prompts might not look like we expect them to. The only way to really fix this is to use a better way of dispatching commands, like the newer "context" system.
However, it's awkward to convert everything to "context" right at the moment, so we're still relying on some tests that do work most of the time. It is, however, particularly sensitive to fancy coloured prompts using escape sequences. Currently we try to handle this by stripping actual ESC characters with tr, then looking for some common variants.
We can do a bit better: instead strip all escape sequences using sed before looking for our prompt. Or, at least, any one using [a-zA-Z] as the terminating character. Strictly speaking ANSI escapes can be terminated by any character in 0x40..0x7e, which isn't easily expressed in a regexp. This should capture all common ones, though.
With this transformation we can simplify the list of patterns we then look for as a prompt, removing some redundant variants.
Signed-off-by: David Gibson
I didn't forget about this one, but I had unrelated test failures which I wasn't sure about. This is actually fine though. Applying soon.
I don't think there's any particular need to make a release for it, but it would be nice to get this in the main git tree, so I don't have to keep awkwardly carrying it about to test my other branches.
Okay, merged just this one without re-testing. -- Stefano
participants (2)
-
David Gibson
-
Stefano Brivio