Anybody want to fix ash's backspace line wrap?

[Rob Landley]

On Wednesday 13 May 2009 19:51:22 Cathey, Jim wrote:
> >Unix started out on teletypes, and still thinks it's talking to a
>
> keyboard
>
> >connected to a daisy-wheel printer via a serial port with a defined
>
> baud
>
> ASR-33, usually.  Pre-daisy-wheel.  Used ed on one of those a fair
> bit back in school.
>
> >Also, the first version of Unix was written in 1969.  DEC's VT100
>
> started
>
> >shipping in 1970 and IBM's TN3270 in 1972.  Presumably by "predates by
>
> a
>
> Wiki claims VT100 in 1978, which jibes with my memory.  Its
> escape sequence design pretty much required a microprocessor,
> whereas earlier glass tty's like the ADM-3 were entirely implemented
> in hardware.  Things like the ADM-3 (Or maybe a Perkin Elmer Fox?)
> are where the first bad backspace behavior must have come from,
> and they were probably just emulating most printing terminals that
> really didn't want to reverse-linefeed anyway.  (And even if they
> could, what would be the point in an interactive session?  Ink's
> already down on the paper.)
>
> How things got into the cruddy state they were/are in certainly
> makes sense.  What to do about it, that was/is harder!

These days the program at the other end of your terminal is a piece of 
software, pretty much guaranteed.  It's usually an xterm variant, although it 
could also be a linux kernel virtual terminal or other oddball.  (Note that 
half the com programs just pass data through to the xterm to be displayed 
through to the xterm to be displayed, although they can also fire up curses 
and handle their own escape sequences for no readily apparent reason.)

We already assume we have something parsing ANSI X3.64 standard escape 
sequences to handle the _current_ backspace behavior (yes that was withdrawn 
in 1997 when ANSI handed its duties over to ISO, which handed them over to 
EMCA or some such, but the new horribly overcomplicated unreadable piecs of 
rubbish, ala 
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf 
have to be backwards compatible with the mountains of existing unix software.  
If they _didn't_ we wouldn't still be stuck with Unix tty behavior and all 
the termcap/terminfo/curses glue layers to make one piece of software talk to 
another piece of software)...

Sigh.  I'm retreading ground from this thread from 2006, easiest to just point 
you at the previous discussion:

  http://lists.busybox.net/pipermail/busybox/2006-September/058645.html

Paul Fox already wrote code to do this (outside busybox), it's just that's 
about the time that Bruce Perens started trolling the list and I stopped 
contributing to busybox because of it.  I was just suggesting we dig up a 3 
year old idea from back when I was last active on this project, and actually 
slot it in since it's actually fairly small and simple and would 
significantly improve the UI on a common use case for busybox (serial 
consoles), which was the same general use case that this thread was about:

  http://lists.busybox.net/pipermail/busybox/2008-October/033325.html

And even deals with the same kind of escape parsing that could be genericized 
(if it hasn't already, I haven't looked in the past 6 months...)

I expected Denys to browbeat me into doing the actual work (his prerogative).  
I didn't really expect people questioning the validity of the problem, since 
it's so easy to reproduce.  (I don't consider "oh but that's always been 
broken" to be a valid excuse.  Call me crazy...)

> >The Commodore 64 made this easy, as did DOS.
>
> Neither of which had a universal I/O redirection model,

And the shell complains when it hasn't got a pty and thus has disabled job 
control.  (The Defective Annoying SHell in Ubuntu doesn't even provide a 
_prompt_ when you don't give it a controlling tty.)  We're already detecting 
the different cases and changing behavior significantly.  Have been all 
along.

I'll grognard right back at you if you like (http://landley.net/history/mirror 
is a hobby of mine, and someday I hope to finish scanning in the hundreds of 
other old magazines in my collection into http://landley.net/history/scans), 
but I don't think this is the appropriate place for it.

> >Both ash and bash clear the screen when you hit ctrl-L.  That's not
>
> _quite_
>
> >the same thing as getting the line editing metrics right.
>
> Guess I'm thinking of ksh, which did not do this.  Seems dumb to
> also do the formfeed action as well in such an interactive editing
> session.

I note that the _reason_ they implemented this redraw behavior was because 
back before the introduction of V.42 error correction you needed to be able 
to redraw to counteract line noise.  (300 baud modems loved dropping curly 
brackets all over the place, you needed to know if the _other_ side saw it 
and was echoing it back to you, or if it was just an artifact at your end.)

We can make the correct behavior entirely automatic and transparent.  The 
existence of manual overrides predating the CCITT protocols for "38.4" are a 
workaround at best, not a fix.

Uphill!  Both ways!  In the snow!

  http://www.youtube.com/watch?v=EGHut3IlJ_Y
  http://landley.net/history/catfire/S-100.mp3
  http;//landley.net/history/catfire/wheniwasaboy.mp3

:P

(Yes, I'm aware Linus Torvalds is a couple years older than me, why do you 
ask?)

> Csh also had some equivalent repaint character, but I 
> think it was different than ksh's.  Neither cleared the screen
> when you called for a refresh of the current line due to external
> (asynchronous) I/O activity that polluted the view.

I think that getting backspace right across line breaks and manually resetting 
the screen once it's gotten screwed up are two separate issues.  This is just 
my opinion, of course...

> -- Jim

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds