brian@radio.astro.utoronto.ca (Brian Glendenning) (01/07/90)
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. In particular, about every other character forces a beep from the shell using the default e71, they all echo ok at n81, but escape codes get fouled up. Has anyone else seen this? System: Sun-3/180, SunOS 4.0.3, standard ttytab/gettytab 2400 baud modem entries. Brian -- Brian Glendenning - Radio astronomy, University of Toronto brian@radio.astro.utoronto.ca uunet!utai!radio!brian glendenn@utorphys.bitnet
news@bbn.COM (News system owner ID) (01/10/90)
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. In particular,
< about every other character forces a beep from the shell using the
< default e71, they all echo ok at n81, but escape codes get fouled up.
Bash 1.04 seems to be ignoring the parity setting (and resetting it).
(Hint: this is unwise...) It looks like 1.02 was doing the right
thing; that behaviour should probably be restored.
-- Pauljr@bbn.com (John Robinson) (01/18/90)
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. In particular, >< about every other character forces a beep from the shell using the >< default e71, they all echo ok at n81, but escape codes get fouled up. > >Bash 1.04 seems to be ignoring the parity setting (and resetting it). >(Hint: this is unwise...) It looks like 1.02 was doing the right >thing; that behaviour should probably be restored. Yeah, I am seeing something like this too. Worked okay in 1.03 as best I can recall. Passing through a telnet connection seems to insulate the modem/terminal from bash, as a workaround. I will test this against a Vax-Ultrix bash-1.04 tonight or tomorrow night. Possibly related, in an xterm (X11R4) window I find that bash is forcing the stty pass8 bit (Sun OS3.5; 3/50M) off on me; for a workaround I put a "stty pass8" in my PROMPT_COMMAND (kludgy). Anyone understand this? Is there some way to tell bash to leave the tty modes alone? -- /jr, nee John Robinson Life did not take over the globe by combat, jr@bbn.com or bbn!jr but by networking -- Lynn Margulis
jr@bbn.com (John Robinson) (01/18/90)
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
brian@radio.astro.utoronto.ca (Brian Glendenning) (01/18/90)
>>>>> On 18 Jan 90 06:12:12 GMT, jr@bbn.com (John Robinson) said:
jr> With a hint from Brian (diff showing his mods to disable all 8-bit
jr> operations about at line 2000 of readline.c), I figured out what bash
jr> [...]
I discovered a problem with my changes. For the record I simply did:
*** readline.c Wed Jan 17 15:11:34 1990
--- readline.c~ Sat Nov 4 08:42:01 1989
***************
*** 1994,2000 ****
/* If this terminal doesn't care how the 8th bit is used,
then we can use it for the meta-key.
We check by seeing if BOTH odd and even parity are allowed. */
! if (0)
{
#ifdef PASS8
the_ttybuff.sg_flags |= PASS8;
--- 1994,2000 ----
/* If this terminal doesn't care how the 8th bit is used,
then we can use it for the meta-key.
We check by seeing if BOTH odd and even parity are allowed. */
! if ((the_ttybuff.sg_flags & (ODDP | EVENP)) == (ODDP | EVENP))
{
#ifdef PASS8
the_ttybuff.sg_flags |= PASS8;
Which I thought was a fairly foolproof thing to do. However now I
discover that delete in user programs doesn't remove the deleted text,
e.g. if I'm sending mail, and am typing in the subject, decide I made
a mistake, hit delete a few times, the characters disappear
"internally" but remain on the screen.
I don't know that much about terminal modes (obviously!). Suggestions?
Brian
--
Brian Glendenning - Radio astronomy, University of Toronto
brian@radio.astro.utoronto.ca utai!radio.astro!brian glendenn@utorphys.bitnetjacob@gore.com (Jacob Gore) (01/19/90)
/ gnu.bash.bug / jr@bbn.com (John Robinson) / Jan 17, 1990 / > 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. What about the LPASS8 flag in the local flags word? Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob