mouse@thunder.mcrcim.mcgill.edu (der Mouse) (03/15/91)
In article <MAYER.91Mar11104808@porky.sono.uucp>, sono!mayer@sun.com (Ronald &) writes: > On a sparcstation, SunOS 4.1 I am having a problem using the termio > ioctl TIOCSTI [...]. While we're on the subject of TIOCSTI under SunOS 4.x.... I find that using TIOCSTI to push back the literal-next character is broken. On real Berkeley, doing this does what one would expect: the next character typed is literal-nexted. On SunOS 3.5, it works the same way. But under releases 4.0.3, 4.1, and 4.1.1, at least, doing this causes the pushed-back literal-next to quote itself somehow, rather than quoting the next character typed. Anybody have any idea when Sun will fix this? And in the meantime, anybody have any idea what I might be able to do as a workaround? Losing literal-next is a major pain. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
guy@auspex.auspex.com (Guy Harris) (03/17/91)
>I find that using TIOCSTI to push back the literal-next character is >broken. On real Berkeley, doing this does what one would expect: the >next character typed is literal-nexted. On SunOS 3.5, it works the >same way. But under releases 4.0.3, 4.1, and 4.1.1, at least, doing >this causes the pushed-back literal-next to quote itself somehow, >rather than quoting the next character typed. Well, SunOS 4.x's tty drivers (yes, "drivers"; in 4.x, TIOCSTI is implemented by the device driver, not by "ldterm") implement TIOCSTI by sending the character in question upstream as if it had arrived as input, which makes it unlikely that it would be broken in the fashion you describe. However, just to make sure, I tested it, with the following program: #include <termios.h> main() { struct termios termios; if (ioctl(1, TCGETS, &termios) < 0) { perror("TCGETS"); return 2; } if (ioctl(1, TIOCSTI, &termios.c_cc[VLNEXT]) < 0) { perror("TIOCSTI VLNEXT"); return 2; } if (ioctl(1, TIOCSTI, &termios.c_cc[VERASE]) < 0) { perror("TIOCSTI VERASE"); return 2; } return 0; } and, as I'd expected, after running that program in cooked mode under the C shell, a DEL appeared as input (DEL being my erase character). Under what circumstances did you get the behavior you describe?
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (03/23/91)
In article <6688@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: [missing attribution: the next paragraph is my text. -dM] >> I find that using TIOCSTI to push back the literal-next character is >> broken. On real Berkeley, doing this does what one would expect: >> the next character typed is literal-nexted. On SunOS 3.5, it works >> the same way. But under releases 4.0.3, 4.1, and 4.1.1, at least, >> doing this causes the pushed-back literal-next to quote itself >> somehow, rather than quoting the next character typed. > Well, SunOS 4.x's tty drivers (yes, "drivers"; in 4.x, TIOCSTI is > implemented by the device driver, not by "ldterm") implement TIOCSTI > by sending the character in question upstream as if it had arrived as > input, which makes it unlikely that it would be broken in the fashion > you describe. > However, just to make sure, I tested it, [...] [program, using TIOCSTI to push back LNEXT, then ERASE] > and, as I'd expected, after running that program in cooked mode under > the C shell, a DEL appeared as input (DEL being my erase character). > Under what circumstances did you get the behavior you describe? I did some experimenting, and the crucial thing seems to be that I had CBREAK mode turned on. Further experimenting seems to indicate that the problem actually is that literal-next simply does not work when CBREAK is enabled, an even worse problem, because it means that a program doing cbreak-style input leaves the user no way whatever to input the special characters. If you prefer, feel free to take that as the complaint instead :-) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
guy@auspex.auspex.com (Guy Harris) (03/28/91)
>Further experimenting seems to indicate that the problem actually is >that literal-next simply does not work when CBREAK is enabled, an even >worse problem, because it means that a program doing cbreak-style input >leaves the user no way whatever to input the special characters. Well, not quite. Literal-next *does* let you escape, say, your interrupt character when CBREAK is enabled. However, the literal-next character gets left in the input queue, so you can't *just* type a ^C (or whatever) at the system; it'll see the ^V (or whatever) as well. A fairly straightforward bug, with what I think is a fairly straightforward fix. I'll forward the fix to Sun, and also post it to "comp.bugs.sys5", as the bug in question may also be present in the S5R4 "ldterm" streams module (which is derived from some version of the SunOS 4.x one).
rbj@uunet.UU.NET (Root Boy Jim) (03/28/91)
In article <1991Mar23.081311.10785@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
? I find that using TIOCSTI to push back the literal-next character is
? broken. On real Berkeley, doing this does what one would expect:
? the next character typed is literal-nexted. On SunOS 3.5, it works
? the same way. But under releases 4.0.3, 4.1, and 4.1.1, at least,
? doing this causes the pushed-back literal-next to quote itself
? somehow, rather than quoting the next character typed.
Sounds like they fixed a bug. My preference would be for STI to
push a character onto the CANONICAL QUEUE. I know what I want
my program to see, why should I have to worry what state
the user or tty are in?
--
[rbj@uunet 1] stty sane
unknown mode: sane