1. Immediately ignore all the signals we want to ignore and set the alarm.
2. Before we exit on error, restore all signals we modified
3. Before we exec a shell, restore all signals we modified and ignore TSTP.
Job control aware shells know how to deal with this.
4. Temporarily handle SIGINT while we read motd.
with MKPIC=no, possibly because the target does not support shared
libraries, these include libraries required to resolve all symbols
which end up referenced from PAM-using applications. The libraries
presently required are -lcrypt, -lrpcsvc and -lutil.
Add use of these variables which are currently set up to use PAM,
so that they compile when MKPIC=no.
Also, in the telnetd case, reorder the order of the libraries, so
that libtelnet.a comes before -ltermcap and -lutil, again to fix
link error when MKPIC=no.
Discussed with thorpej and christos.
addition to the host name. This option is needed by programs suchs as
telnetd, because at the point they invoke login, they already have opened
a pty, and the stdin of login is no longer the socket connected to the
remote host. In addition don't chop the hostname up to the first dot if
the domain matches. These practices are 70's fashion and they only serve
to lose information. These days we have long enough fields in utmpx and
wtmpx to store the full names.
and without Kerberos 4 & 5 (MKKERBEROS=no). Previously checkflist
complained of missing files.
* move kerberos- and kerberos 4-only files into new flists,
distrib/sets/lists/*/krb.*
* make the flist generators grok MKKERBEROS{,4} variables
* fix Makefiles which treat MKKERBEROS=no as MKKERBEROS5=no.
9 out of 10 experts agree that it is ludicrous to build w/
KERBEROS4 and w/o KERBEROS5.
* fix header files, also, which treat MKKERBEROS=no as MKKERBEROS5=no.
* omit some Kerberos-only subdirectories from the build as
MKKERBEROS{,4} indicate
(I acknowledge the sentiment that flists are the wrong way to go,
and that the makefiles should produce the metalog directly. That
sounds to me like the right way to go, but I am not prepared to do
revamp all the makefiles. While my approach is expedient, it fits
painlessly within the current build architecture until we are
delivered from flist purgatory, and it does not postpone our
delivery. Fair enough?)
mrg