Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!bbn!jr@bbn.com From: jr@bbn.com (John Robinson) Newsgroups: gnu.bash.bug Subject: Re: Bash-1.04 and modems Summary: it can work, but it ain't pretty Message-ID: <51066@bbn.COM> Date: 18 Jan 90 06:12:12 GMT References: <50659@bbn.COM> <51045@bbn.COM> Sender: news@bbn.COM Reply-To: jr@bbn.com (John Robinson) Distribution: gnu Organization: BBN Systems and Technologies Corporation, Cambridge MA Lines: 86 In-reply-to: jr@bbn.com (John Robinson) 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