Discussion:
[ast-users] ksh 93u+ emitting too many backspaces on filename completion
Norman Ramsey
2016-09-05 21:26:03 UTC
Permalink
In the last few weeks or months I have gotten my system into a strange
state whereby when I try filename completion with ESC ESC or with TAB,
ksh completes the file but also sprays a CR and bunch of backspaces
into the terminal. To add insult to injury, I cannot reproduce this
behavior consistently when ksh is running under 'script'.

I have had the same ksh for a long time, so I suspect that some other
component of the system is feeding ksh bad information, but I would
welcome thoughts about how to diagnose the problem.

In all examples I hit ESC ESC after the 'b' in 'debian'.
Here is what it looks like when things are working correctly:

: ***@homedog 11054 ; ls
bin debian lib README src
: ***@homedog 11056 ; script /dev/null
Script started, file is /dev/null
: ***@homedog 11057 ; ls debian/
changelog control docs menu postrm shcomp.1
clean copyright example.kshrc patches prerm source
compat dirs fr-shcomp.1 postinst rules
: ***@homedog 11058 ; ls debian/
changelog control docs menu postrm shcomp.1
clean copyright example.kshrc patches prerm source
compat dirs fr-shcomp.1 postinst rules
: ***@homedog 11060 ;
Script done, file is /dev/null

And here is what the terminal looks like after running *not* under
'script':

s debian/
changelog control docs menu postrm shcomp.1
clean copyright example.kshrc patches prerm source
compat dirs fr-shcomp.1 postinst rules
: ***@homedog 11060 ;

I did manage to get it to fail once under 'script', and this is what
is happening (binary version attached; control characters rendered
here using ^):

Script started on Mon 05 Sep 2016 05:01:48 PM EDT
ksh[1]: branchdisplay: not found [No such file or directory]^M
: ***@homedog 11019 ; ls deb^M: ***@homedog 11019 ; ls debian/ ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^M
changelog clean compat control copyright dirs docs example.kshrc fr-shcomp.1 menu patches postinst postrm prerm rules shcomp.1 source^M
ksh: branchdisplay: not found [No such file or directory]^M
: ***@homedog 11020 ; ^M

Script done on Mon 05 Sep 2016 05:01:59 PM EDT

This behavior is what I might expect from a full-size xterm of 200
columns, which I do use occasionally. But I get the behavior even in
a fresh xterm where COLUMNS is 80 and has always been 80. And it is
putting my xterms into a strange state.

My question for the list: where in the ksh source code can I find the
routines that are responsible for managing the terminal, so I can try
to diagnose this issue?


Norman Ramsey
Norman Ramsey
2016-09-06 20:30:47 UTC
Permalink
> In the last few weeks or months I have gotten my system into a strange
> state whereby when I try filename completion with ESC ESC or with TAB,
> ksh completes the file but also sprays a CR and bunch of backspaces
> into the terminal.

Followup: I got a little help, and the problem is in my $PS1,
which was set to

": ***@homedog ! $(branchdisplay) ; "

Apparently ksh is trying to backspace over the characters in
"$(branchdisplay)", not realizing that these characters produce no output.
This behavior triggers some kind of fault (or at least strangeness)
in xterm.

I worked around the problem by updating my keyboard trap to run the
'branchdisplay' function and set PS1 every time a $'\r' is entered.


Norman
Loading...