[Pkg-shadow-devel] Bug#221290: Bug #221290 still here: screen garbled after entering high-ascii characters at login prompt

[Alexander Gattin]

reassign 221290 util-linux
thanks

Hi!

On Thu, Sep 29, 2005 at 05:53:40PM +0200, Helge Kreutzmann wrote:
> first of all, I found out, that if I enter a "sane" login name (does
> not need to exist) and press enter twice, then I can safely enter
> umlauts, even delete them (no visual artefacts) and everything is fine
> after login.

This is because several subsequent "login:" prompts are
provided and processed by /bin/login, not by getty.

After several attempts failed (or timeout expired)
/bin/login exits and /sbin/getty is restarted on this
tty by /sbin/init...

> So only the first call to getty is vulnerable to this
> effect. If I exceed the "maximum number of tries", the next getty is
> back to the "old" behaviour, with visual artefacts and so on.

Yes, because actually those are different "login:"
prompts, some provided by /sbin/getty and some by
/bin/login (as explained above). Visual appearance of
those "login:" prompts is the same though, and this is
done intentionally, I think.

This is confusing, of course, but IIRC this behaviour
is in Unices since ages.

> It works as intended.

Good. :^)

> correctly). So I guess the next step would be to find out where the
> default settings are stored, so that the wrapper could retrieve the
> default set instead of hard coded corrections?

IMHO, getty could be patched easily, maybe some option
may be added to suppress "tty-bitness-autodetection"
feature and this would be done by people with more
experience WRT linux console (and other kinds of ttys),
so I wouldn't perhaps want to extend/improve the
wrapper script further.

But more important reason is that I just don't know how
to find this "sane" set of options/defaults for linux
virtual console... :-/ I.e. at the moment I don't have
any clue about this.

> Should we reassign to getty?

Yes, /sbin/getty is in util-linux package, thus
reassigning to its authors.

P.S.
On my system /sbin/getty is run with nothing regarding
locale in environment (you can check this with
`ps -C getty ue | less`), so it's effectively in "POSIX"
locale, I think.

IMHO, all this tty-tuning should be done independently
of locale/system locale etc. There are some scripts for
setting keymap, console fonts, switching virtual
console to utf8 mode and so on, and I think that _only_
these scripts should "tune" linux virtual consoles,
while getty shouldn't touch them afterwards...

-- 
WBR,
xrgtn