🚀 go-pugleaf

In article <51045@bbn.COM>, jr@bbn (John Robinson) writes:
>In article <50659@bbn.COM>, pplacewa@antares.bbn.com (Paul W Placeway) writes:
>>brian@radio.astro.utoronto.ca (Brian Glendenning) writes:
>>< 
>>< I have been using bash-1.02 instead of 1.04 for a while because when I
>>< use bash-1.04 over a modem something weird happens.
>>
>>Bash 1.04 seems to be ignoring the parity setting (and resetting it).
>>(Hint: this is unwise...)
>
>Yeah, I am seeing something like this too.  
>
>Possibly related, in an xterm (X11R4) window I find that bash is
>forcing the stty pass8 bit [...] off on me.
>
>Anyone understand this?  Is there some way to tell bash to leave the
>tty modes alone?

With a hint from Brian (diff showing his mods to disable all 8-bit
operations about at line 2000 of readline.c), I figured out what bash
(really, readline) is trying to do.  I'll describe that, and how I am
able to work right now.  Then I'll propose a different way to handle
this.

First of all, if you have the termio library, none of this applies.
The terminal modes, at least those related to character size and
parity, are a lot more rational in termio, and though I didn't read
the alternate code I'd expect that this can be done right.  Termio is
in SysV, implying also SunOS 4.0 and newer, and recent Ultrix, among
others.  For the rest of us ...

Here's what readline does before starting interactive line-editing.
It looks at the settings of the two parity bits (stty even and stty
odd).  If both are on, it assumes that the user doesn't care about the
8th bit: "how could anyone want both even and odd parity?  They *must*
be telling bash to enable the 8th bit".  Well, this doesn't fly,
because there are two other kinds of "parity", mark and space.  Mark
means the 8th bit should always be set (implying 7-bit characters,
with one more stop bit than you think, though the serial chip may
distinguish for other reasons).  Space means the 8th bit should always
be 0.

If the test succeeds on the parity bits in stty, readline turns on the
PASS8 bit in the "local" part of the stty word.  This allows the
application to see all 8 bits on input, and to generate all 8 bits on
output.  But what should the 8th bit be (on output)?  To me, both bits
on would imply that mark parity shoud be used, and both off would
imply space.  In fact, readline never sets the 8th bit on sending.  So
you terminal will (a) reject every character if it is expecting mark
parity, (b) reject half of them expecting odd, or (c) reject the other
half expecting even.  It may feep at each parity "error".  So you
should (if your terminal allows it) set it for "space" parity.  Or
disable parity checking altogether.

Do you see the problem?  The v7 and/or bsd "new" tty model of the stty
flags doesn't really allow you a way to talk about space or mark
parity.  Termio does; I suspect posix, which is supposed to be close
to termio, also does.  [This is based on a cursory (no pun!) reading
of the Ultrix stty man page - Ultrix figured they'd better allow
everything and has 4 line disciplines: old, new, termio and posix!]

So what about xterm?  Apparently, it starts up your application with
the pty's terminal modes set with both parity flag bits off (stty -odd
-even).  readline won't turn on pass8 by itself, so characters are
un-meta-ized by the input driver.  To get bash to work properly in an
xterm window, I had to add a "stty odd even" to by .bashrc, when $TERM
is xterm.

So this cleverness in bash 1.04 hit 0-for-2 for me.  Ugh.

Recommendation:

Find a better way to infer when it is okay to turn on PASS8.  I don't
believe there is any decent way to do it from the "new" tty stty
flags.  Instead, I think this should be controlled from a bash (or
readline?) flag.  [I don't konw - are there flags you can put in your
environment so that each readline application, such as gdb, will also
get them?].  Also, it could perhaps be conditioned on the has-meta-key
(:km:) property in termcap, though this is undocumented and may not be
in wide use.  But fixing one termcap file may be preferable to getting
each user to fix their .bashrc.  So my vote is for paying attention to
the :km: capability, plus having a way (if necessary) to assert this
capabilty if readline has to operate absent termcap.
--
/jr, nee John Robinson     Life did not take over the globe by combat,
jr@bbn.com or bbn!jr          but by networking -- Lynn Margulis