-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Please Cc me in replies, as I am not subscribed here.)
A user reported some annoying/puzzling behavior when running GNU Screen
under bash under eterm: Every prompt would be preceded by the current
working directory path, preceded by an extra slash. For example, instead
of the usual:
prompt$ echo Hello
Hello
prompt$
The user would get:
//home/user
prompt$ echo Hello
Hello
//home/user
prompt$
After some investigation, I found that bash tries to detect when it's
running under an Emacs terminal (looks for the string "term" within the
env var EMACS, within main), and when that's the case, will issue the
SUB control, followed by a slash and then the CWD (and a final newline).
Screen doesn't know what to do with the SUB (0x1A) character. If it
passed it straight through and then interpreted following characters as
usual, it's understanding of what should be placed in the image buffer
and where the cursor's current position is, would be mistaken. OTOH, if
it interpreted SUB the way eterm does, it would fail to be portable to
other terminals. So I believe screen's current behavior (ignoring SUB)
to be correct.
Still, it's not fun for users to see bash's underwear hanging out like
that. An easy workaround is to unset EMACS (or at least reset it so it
doesn't contain the word "term"); but I wonder whether the check could
be made a little more robust: perhaps if, in addition to checking the
value of EMACS (which screen won't know to change), it also verifies
that TERM=eterm (which screen would normally change to "screen" or
somesuch)?
(This issue affects the latest available Bash release, version 3.2.)
- --
Thanks,
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer,
and GNU Wget Project Maintainer.
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIc/YJ7M8hyUobTrERAponAJ0SQ0QVpSymACSHlU0WC/RsLp1o4gCgkqkr
c0hNcI2aaEUZgVPuusby27Q=
=i2n6
-END PGP SIGNATURE-
