/etc/getty bashing (Re: configuring FAS)
Martin Weitzel
martin at mwtech.UUCP
Sat May 4 11:48:26 AEST 1991
In article <1991May1.222641.16308 at unixland.uucp> bill at unixland.uucp (Bill Heiser) writes:
>[...] just noticed that HUPCL was mistyped
>(by yours truly no less) as HUCPL. hmmm.. Funny that GETTY didn't
>notice that [...]
I just checked what "/etc/getty -c /etc/gettydefs" tells in these case
and it seems that it trys to inform about the problem (at least on ISC 2.2).
Unfortunately output is so voluminous that the particular error message
ist hard to see for any practical gettydefs-file with some ten entries.
(A quick workaround would be to pipe the output to grep and look for
the string "unknown".)
The behaviour of /etc/getty (when run for its "real purpose", not with the
-c option to check a gettydefs-file) could be justified with the arguments
that you generally don't want to lock anybody out if there is one single
bad entry (maybe due to a typo). So getty is right to simply ignore bad
parts of an entry.
You may say that it should tell about the problem, but whom? The one who
logs in? Of course any conscious administrator would login after a change
to the gettydefs file to see if anything is wrong - but then he could as
well run "getty -c ...." for the check. Furthermore, if the administrator
configures an entry for a modem lione, there will often be no possibility to
check without a call from outside, so again "getty -c ...." serves better.
On the other hand, at least the older versions of /etc/getty surely *are*
braindead in some areas:
Why did they insist on "one-line" entries, especially where
typical gettydefs-entries are by far longer than the lines
on a typical screen? Is it really so hard to implement
continuation lines in the usual way, i.e. terminating
backslash.
(Seems to be cured in ISC UNIX 2.2 at least - but not with
\-line ending, but as long as you have no empty line the next
line is seen as part of the current entry.)
Why did they insist on exactly ONE blank line AFTER each entry?
Note that there also had to be one blank line after the last
entry before the end of the file. It was easy to miss this if
you added a new entry at the end!
(Seems also to be cured in ISC UNIX 2.2 at least - deleting the
empty line at the end of the gettydefs-file seems not to produce
any ill effects.)
Why can I only specify TTY-modes but no TTY-control characters,
i.e. kill, erase, eof, ...?
(This still exists today - or any change remained an undocumented
feature.)
As a last example for bad design take the typical gettydefs-file on a
system with virtual screens: Many entries are exact duplicates, except
for the login prompt (VT01 login:, VT02 login:, ...). There should really
be a special syntax for embedding things like tty-port or system-name in
the login prompt. I've seen such a thing on SCO-UNIX some time ago. If I
remember it right, \@ in the prompt string expanded to the system's name.)
--
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83
More information about the Comp.unix.sysv386
mailing list