Re: Stty bug?

[Alan Curry]

Bob Proulx writes:
> 
> Alan Curry wrote:
> > I believe -iexten may be the problem. In your tty1 test, was iexten enabled?
> > Maybe a getty bug, it should be turning on iexten if it turns on iuclc.
> 
> I was able to recreate the original problem.  Reading Alan's response
> here I was surprised to see that adding iexten to iuclc did enable the
> desired behavior.  This would not have been required on traditional
> systems and its combination here isn't obvious to me.  There doesn't

Indeed, I believe iexten should be enabled by default, and my hazy memory
tells me it used to be. Turning it off is like saying "please punish me with
minimal POSIX tty capabilities"

> seem to be very much documentation available about iexten.  I am
> curious how you deduced that adding it would produce the desired
> behavior?

First, I saw -iexten in a report of tty misbehavior and got suspicious of it
right away since it's caused trouble for me before (lnext and werase are
useful!). Then I grepped to confirm it:

$ cd linux/drivers/char
$ grep IUCLC *.c
n_tty.c:        if (I_IUCLC(tty) && L_IEXTEN(tty))
n_tty.c:        if (I_ISTRIP(tty) || I_IUCLC(tty) || I_IGNCR(tty) ||

Bingo!

> 
> The documentation says:
> 
>   $ info coreutils 'stty invocation'

But at the next layer down, the documentation says:

$ man 3 tcsetattr
       IEXTEN Enable  implementation-defined  input processing.  This flag, as
              well as ICANON must be enabled for the special characters  EOL2,
              LNEXT, REPRINT, WERASE to be interpreted, and for the IUCLC flag
              to be effective.

Should the stty documentation try to describe every platform-dependent
combination of flags? That kind of manual can get bloated, and you end up
forcing everyone to read about the quirks of everyone else's platform,
instead of telling them how to use the one they're using.

> By my reading that doesn't give any hint that iexten is required for
> iuclc to function.  And indeed it isn't needed on a pty.  I don't

I tried it myself on a pty and couldn't reproduce your result.

> 
> I still think this is simply a Linux kernel tty driver bug.  I haven't
> looked at the code there yet though.

POSIX describes IEXTEN as "Enable extended input character processing." Does
that include the "processing" done by IUCLC, or does it just mean control
characters? You can argue that with the kernel mailing list if you want.

I still put most of the blame on getty. tty_std_termios (the kernel's
"default default" tty settings, which most drivers use to set the default
mode on a new tty) has IEXTEN enabled. getty is overriding the kernel's
default by setting all the flags to 0, and then turning on the ones it knows
about, and it doesn't know about IEXTEN.

This is what I'm seeing on Debian stable, where the "getty" is really agetty
from util-linux. I assume Ubuntu is the same.

-- 
Alan Curry