Multiply-defined sgtty characters?
Guy Harris
guy at auspex.UUCP
Fri Nov 11 05:33:06 AEST 1988
> What it does is to assign an additonal character to EOF.
No, you misunderstand the way the BSD "stty" command reports control
character settings; it doesn't assign it to the EOF character, it
assigns it to what in V7/BSD land is called the "break" character and in
S3/S5 land is called the "end-of-line" character. This character acts
as an "alternative end-of-line" - it basically behaves like NEWLINE, in
that it causes the line currently being edited to be completed, and
becomes the last character on the line.
>This is anything but desirable, since unlike the normal csh, ESCAPE is
>treated specially outside the command line.
The 4.3BSD "csh" appears (at least in its SunOS 4.0 incarnation, and
probably elsewhere as well) to have the end-of-line character set to
ESCAPE *only* when it is reading from the terminal; it politely disables
the end-of-line character when it gives control of the tty to another
program.
If the Ultrix "/usr/new/csh" doesn't do this, it's either a bug or a
misfeature, and should be fixed. I don't know if "/usr/new/csh" is the
4.3BSD C shell, the "tcsh" C shell, or something else.
> I'm not going to bother asking whose idea this was.
Given that the 4.3BSD C shell does not run in "cbreak" mode, wherein it
would see every character as it is typed, it is obliged to set the
end-of-line character to ESCAPE, so that it can at least see the ESCAPE
as soon as it is typed, instead of requiring you to type ^D after it.
As such, it is a good idea, as long as it puts things back the way they
were when it runs another program.
>What I would like to know is whether or not stty will let me clear this
>extra character.
Yes. You have to ask it to change the "break" character; asking it to
change the EOF character won't help. Assuming the Ultrix "stty" is
basically the 4.3BSD one, you would do
stty brk undef
Of course, if the C shell detects that the "break" character was turned
off, and turns it back on again, you'd lose; in this case, you'll either
have to not run "/usr/new/csh" or get the bug/misfeature fixed.
More information about the Comp.unix.wizards
mailing list