rs@mirror.UUCP (03/18/86)
In BSD4.2, is there any good reason why /etc/rc shouldn't
have an "exec >/dev/console 2>1" at the top, and punt all
those line-by-line redirections throughout it and rc.local?
--
Rich $alz {mit-eddie, ihnp4!inmet, wjh12, cca, datacube}!mirror!rs
Mirror Systems 2067 Massachusetts Avenue Cambridge, MA, 02140
Telephone: 6,176,610,777gfm@ecs.OZ (Graham Menhennitt) (03/24/86)
In article <13400020@mirror> rs@mirror.UUCP writes: > In BSD4.2, is there any good reason why /etc/rc shouldn't > have an "exec >/dev/console 2>1" at the top, and punt all > those line-by-line redirections throughout it and rc.local? Our company builds a 68000 based machine which runs a v7/sysIII/4.2 mixture. At one stage I altered /etc/init to make the shell that runs /etc/rc have is stin/out/err connected to /dev/console. It worked ok at first. At the time we were developing an intelligent 8 port RS232 board with an on-board 68000. We originally had the local code executed from a PROM but soon decided that software revisions were going to be fairly regular and so replaced the PROMs with RAM. The local code is now downloaded from a UNIX file by /etc/rc. This produces a problem with the above suggestion. The device /dev/console is opened before the local code has been downloaded. I didn't think of doing the "exec >/dev/console 2>1" trick but I expect it would have worked if I had put it after the downloading. --------- Graham Menhennitt ACSnet: gfm@ecs.oz Computer Systems Project Leader UUCP: seismo!mulga!ecs.oz!gfm Email Computer Systems (L&L Australia)
ed@mtxinu.UUCP (Ed Gould) (03/25/86)
> In BSD4.2, is there any good reason why /etc/rc shouldn't > have an "exec >/dev/console 2>1" at the top, and punt all > those line-by-line redirections throughout it and rc.local? YES! Some - perhaps most - of the daemons started by /etc/rc assume that they don't have a controlling terminal. Doing what you suggest would give them one. Many of them will fail miserably, or at least cause their children that open a tty and expect *that* to be their controlling terminal to fail. These failures are often subtle and difficult to diagnose. There's no fundamental reason, now that there is a mechanism by which a process can divest itself of its controlling terminal, that this need continue. It seems wise, though, in the interest of portability, to assume that processes don't necessarily have this ability, and therefore not to use it unless necessary. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."