--- Begin Message ---
|
Subject: |
[PATCH 0/1] environment: Fix '--check' for shells that output ANSI escape codes based on 'TERM'. |
|
Date: |
Thu, 2 Mar 2023 21:25:35 -0500 |
Hi,
I ran into an issue where 'guix shell --check' would fail on Debain 11's Bash,
even though the environment variable it was complaining about not being set was
in fact set.
As far as I can tell, the issue is caused by Bash's support for bracketed paste
[0], which is causing it to output "\x1b[?2004l\r" before the script output,
leading the first vhash entry to be invalid (in the sense that
'validate-child-shell-environment' will never see it).
Per ncurses' terminfo database [1], setting it to nothing (which is "unknown,"
per my understanding/testing with 'tput') is the same as setting it to "dumb,"
which will hopefully get us in the clear for the future, assuming shells play
nice with regards to terminal specifications and detection.
Given this, there are a few alternative solutions that I'd like to propose:
1. Set 'TERM' to 'dumb'. This has the benefit of being explictly specified in
the terminfo database, though any sane implementation should(?) fall back to it
if it's set to nothing instead.
2. Use the shell non-interactively, if possible, and fall back to the script in
interactive mode. We'd have to assume that the shell takes some sort of
argument for a command (e.g. '-c'/'--command'), though based on the fact that
we currently don't do that, I assume it's for a good reason.
3. Strip ANSI escape codes when adding the lines to the list. This might be the
best one, though I'm unsure how best to do it. A PEG parser? A regex?
This was definitely an interesting issue to look into, and I look forward to
thoughts on the matter.
Thanks,
Winter
P.S. I've seen a few commit prefixes that touch 'guix/scripts', like
"environment" (as I've used here, since it seems to be the most prominent) and
"guix: shell". Is one more correct than the other?
[0]:
https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_Sequence_Introducer)_sequences,
under "Some popular private sequences"
[1]: https://invisible-island.net/ncurses/terminfo.src.html#tic-unknown
Winter (1):
environment: Unset 'TERM' when checking environment.
guix/scripts/environment.scm | 2 ++
1 file changed, 2 insertions(+)
base-commit: ea870a70e93e7ea93e35fa8e0afc3cfdb1b66ba2
--
2.39.1
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#61927: [PATCH 0/1] environment: Fix '--check' for shells that output ANSI escape codes based on 'TERM'. |
|
Date: |
Mon, 13 Mar 2023 14:21:44 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi Winter,
Winter <winter@winter.cafe> skribis:
> I ran into an issue where 'guix shell --check' would fail on Debain 11's
> Bash, even though the environment variable it was complaining about not being
> set was in fact set.
OK.
> As far as I can tell, the issue is caused by Bash's support for bracketed
> paste [0], which is causing it to output "\x1b[?2004l\r" before the script
> output, leading the first vhash entry to be invalid (in the sense that
> 'validate-child-shell-environment' will never see it).
I didn’t know about bracketed paste; my understanding is that it’s the
terminal that emits those sequences, and Bash is merely supposed to
interpret them no? (E.g., Bash should make sure pasted text is not
immediately executed.)
Regardless, there’s the possibility of such escape sequences popping up.
> Per ncurses' terminfo database [1], setting it to nothing (which is
> "unknown," per my understanding/testing with 'tput') is the same as setting
> it to "dumb," which will hopefully get us in the clear for the future,
> assuming shells play nice with regards to terminal specifications and
> detection.
>
> Given this, there are a few alternative solutions that I'd like to propose:
>
> 1. Set 'TERM' to 'dumb'. This has the benefit of being explictly specified in
> the terminfo database, though any sane implementation should(?) fall back to
> it if it's set to nothing instead.
> 2. Use the shell non-interactively, if possible, and fall back to the script
> in interactive mode. We'd have to assume that the shell takes some sort of
> argument for a command (e.g. '-c'/'--command'), though based on the fact that
> we currently don't do that, I assume it's for a good reason.
> 3. Strip ANSI escape codes when adding the lines to the list. This might be
> the best one, though I'm unsure how best to do it. A PEG parser? A regex?
I’m fine with setting ‘TERM’ to the empty string or to “dumb”.
Option #2 wouldn’t let us test what we want (we really want to test an
interactive shell); option #3 sounds tricky and fragile to me.
So I tweaked the comment and commit log and applied your patch.
Thank you for the investigation and fix!
Ludo’.
--- End Message ---