generating code to run multiple targets
Karl Kleinpaste
karl at triceratops.cis.ohio-state.edu
Sat Apr 22 01:30:39 AEST 1989
ok at quintus.UUCP (Richard A. O'Keefe) writes:
>But this mechanism allows only one machine type.
>On a Sun-3, for example, I would expect both 'sun' and 'm68k' to be true.
It's precisely for Suns that I wanted it. We have Sun-2s, Sun-3s, Sun-4s,
and a Sun-386i. The question I wanted an answer to was "which of my
~/bin/* directories shall I put in my $PATH", and the answer is
PATH=$HOME/bin/`machine`:$PATH
/bin/arch would have been ideal, except that our Sun-2s run SunOS 2.3,
which hasn't got /bin/arch. Similarly, knowing that a machine is an
Apollo machine isn't enough.
We had this problem in a bad way, and solved it quite some time back
by installing a file /etc/sysinfo on every system we've got, which
describes the system's features appropriately. E.g., on Triceratops,
a Sun3/50, /etc/sysinfo says:
sun3:/vmunix:bsd4.2:sunos3.5.1:/bin/hostname
Other machines nearby say related but significantly different things:
pyr:/vmunix:bsd4.3:osx4.0:/bin/hostname
hp300:/HP-UX:hp-ux:hp-ux6.21:/bin/hostname
u3b2:/unix:sys5:sys5rel3.0:/bin/uname -a
In general:
machine-type:/kernel:most-like-this-UNIX:vendor-calls-it:get-hostname-like-this
The file can be split by the presence of the `:' trivially, and the
usual login procedures around here do this automatically and put
relevant things into environment variables. It works very well, and
avoids the need for more stuff cluttering up /bin by putting all this
info in one place.
--Karl
More information about the Comp.unix.wizards
mailing list