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