martin@mwtech.UUCP (Martin Weitzel) (05/04/91)
In article <1991May1.222641.16308@unixland.uucp> bill@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@mwtech.UUCP, voice: 49-(0)6151-6 56 83