Kemp@DOCKMASTER.NCSC.MIL (04/19/89)
> Tcsh added two environment variables, HOST and HOSTTYPE. . . .
From the SunOS manpage MACHID(1):
"The following commands will return a true value (exit code of 0) if
you are on a processor that the command name indicates.
sun, iapx286, i386, m68k, pdp11, sparc, u3b, u3b2, u3b5, u3b15, vax
The commands that do not apply will return a false (non-zero) value.
These commands are often used within make(1) makefiles and shell
procedures to increase portability.
SEE ALSO
arch(1), mach(1), make(1), sh(1), test(1V), true(1)"
The list of processors implies that this is not a Sun-ism, but comes
with standard BSD 4.x. What have I been missing from this discussion???
Dave Kemp <Kemp@dockmaster.ncsc.mil>andrew@frip.wv.tek.com (Andrew Klossner) (04/21/89)
.>>From the SunOS manpage MACHID(1):
.>> sun, iapx286, i386, m68k, pdp11, sparc, u3b, u3b2, u3b5, u3b15, vax
.>> The list of processors implies that this is not a Sun-ism, but comes
.>>with standard BSD 4.x. What have I been missing from this discussion???
.>I posted a "machine" shell script last year which checks for a whole bunch of
.>machines, it was always the One Right UNIXy thing to have *one* command
.> machine # write the processor type to stdout
.>so that one would simply say
.> case `machine` of ...
But this mechanism allows only one machine type.
On a Sun-3, for example, I would expect both 'sun' and 'm68k' to be true.
-=- Andrew Klossner (uunet!tektronix!orca!frip!andrew) [UUCP]
(andrew%frip.wv.tek.com@relay.cs.net) [ARPA]guy@auspex.auspex.com (Guy Harris) (04/21/89)
>>From the SunOS manpage MACHID(1): >> sun, iapx286, i386, m68k, pdp11, sparc, u3b, u3b2, u3b5, u3b15, vax >> The list of processors implies that this is not a Sun-ism, but comes >>with standard BSD 4.x. What have I been missing from this discussion??? > >There is a core list: u*b*, vax, pdp11 and maybe a couple of others. Yup. The original poster inferred, incorrectly, that most of the items in that list came with standard 4.xBSD. The only ones that did were, I think, "pdp11" (maybe), "vax" (definitely), and possibly "tahoe" (4.3-tahoe). Sun added some themselves ("m68k", "sparc"), picked up some from various 3B flavors of S5 ("u3b*"), and picked up others from descriptions of the AT&T 80286 and 80386 UNIX versions ("iapx286", "i386") - no, even though they're AT&T versions for the 80*86, the commands are *not* in AT&T's 3B versions. However, the core list, meaning the intersection of all the sets of such names provided by all manufacturers, is smaller than the one you list. u3b* come with S5, but not all vendors have them; Sun picked them up in SunOS 3.2. My guess is that the core list is, *at most*, "vax" and "pdp11"; it may well be the empty set.
guy@auspex.auspex.com (Guy Harris) (04/21/89)
>This is a start, but I think that we need a standard way of getting the >CPU type (i386 vs ns32000, for example), operating system type (on >several different levels: Berkeley vs. AT&T Unix, 4.2BSD vs. 4.3BSD, >etc.), Well, unfortunately, for OS type you don't want "Berkeley vs. AT&T UNIX", since there are some systems that aren't pure versions of either; for example, a hell of a lot of systems that advertise themselves as "AT&T UNIX", presumably really meaning "System V" (after all, "Berkeley UNIX" is, to a large degree, derived from a version of "AT&T UNIX"), have job control. (If you consider a system with job control not to be pure "AT&T UNIX", of course, this means System V Release 4 won't be "pure AT&T UNIX". So much for Purity Of Essence....) The same applies for the socket calls, symbolic links, long file names, etc.. You probably don't want "4.2BSD vs. 4.3BSD", either, since there are some systems that aren't pure versions of either (systems that have, for example, picked up some 4.3BSD features but not others). What you really want is a way of asking whether particular features are present, and which version of those features are provided.
barnett@crdgw1.crd.ge.com (Bruce G. Barnett) (04/21/89)
In article <11319@tekecs.GWD.TEK.COM>, andrew@frip (Andrew Klossner) 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. In future SunOS releases (4.0.3?) the command /bin/arch has a '-k' option to indicate the type of kernal. While the Sun 4/110 and Sparkstation are both sparc-based, the kernals (e.g. virtual memory) are very different. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!steinmetz!barnett, <barnett@steinmetz.ge.com>
ok@quintus.UUCP (Richard A. O'Keefe) (04/21/89)
In article <11319@tekecs.GWD.TEK.COM> andrew@frip.wv.tek.com (Andrew Klossner) writes: >.>I posted a "machine" shell script last year which checks for a whole bunch of >.>machines, it was always the One Right UNIXy thing to have *one* command >.> machine # write the processor type to stdout >.>so that one would simply say >.> case `machine` of ... > >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. Even knowing that it is an Apollo and an m68k rather than a DN10000 isn't enough. You don't want to try executing 68020 instructions on a 68010. (Apollo have a $NODETYPE which tells you what you want to know, and my script echoes it if it can.) I don't claim that this is the only question you want to answer, only that it provides users with a single place to look for the answer to this particular question, no matter which of our machines is used.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (04/21/89)
ok@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
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/22/89)
I wonder what GRep, the vendors of the CaT and ED architecture-based UNIX systems, think about /bin/sparc, /bin/sun, et al.
guy@auspex.auspex.com (Guy Harris) (04/23/89)
>I wonder what GRep, the vendors of the CaT and ED architecture-based >UNIX systems, think about /bin/sparc, /bin/sun, et al. Or "/bin/pdp11", dating back to V7.... They were a nice idea, perhaps, but they don't scale well.
dente@s2.uucp (Colin Dente) (04/24/89)
In article <1480@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>>From the SunOS manpage MACHID(1): >>> sun, iapx286, i386, m68k, pdp11, sparc, u3b, u3b2, u3b5, u3b15, vax >>> The list of processors implies that this is not a Sun-ism, but comes >>>with standard BSD 4.x. What have I been missing from this discussion??? >> >>There is a core list: u*b*, vax, pdp11 and maybe a couple of others. > > >However, the core list, meaning the intersection of all the sets of such >names provided by all manufacturers, is smaller than the one you list. >...My guess is that the core list is, *at most*, "vax" and >"pdp11"; it may well be the empty set. Seems to me that this discussion is at two levels: 1) What *should* be done in the future (e.g. implementing a _machine_ command, or somesuch) 2) What can be done now - i.e. just what is there about which can tell you what you are compiling/running on. Whilst I really feel that (1) is very worthwhile - and I'd put my support behind a command/call like machine which returned some standard description of hardware, I think it would really be useful to compile some sort of list of what can be done already. So - all you people who are experts on what can be done on your own pet system either post the details, or mail me, and I'll post a summary - or ignore me completely, and I'll crawl back under my stone - whatever you think the most appropriate. Colin =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Colin Dente | JANET: dente%s2@uk.ac.man.cs.ux | | Dept. of Electrical Engineering | ARPA: dente%s2%man.cs.ux@cunyvm.cuny.edu| | University of Manchester | UUCP: ...!mcvax!ukc!man.cs.ux!s2!dente | | England | | |-----------------------------------------------------------------------------| | ======================================================================= | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=