NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/sgi/16552

Text File | 1992-11-17 | 4.5 KB | 106 lines

Newsgroups: comp.sys.sgi
Path: sparky!uunet!think.com!ames!pioneer.arc.nasa.gov!lamaster
From: [e-mail] (Hugh LaMaster)
Subject: Re: what should an arch command return on an indigo?
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: NASA Ames Research Center, Moffett Field, CA
References: <grl.721642136@groucho> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 17 Nov 1992 20:30:14 GMT
Lines: 94

In article <[e-mail]>, [e-mail] (S.H. Couturie) writes:
|> In article <[e-mail]> [e-mail] (Hugh LaMaster) writes:
|> >In article <[e-mail]>, [e-mail] (Thomas Sippel - Dau) writes:
:
:

|>
|> **** We have, up until now, standardized on the HOSTTYPE names "tcsh" uses;
|>      why reinvent the wheel?

"tcsh" is hardly a standard everywhere.  Also, I don't like some of its name
choices (why don't THEY resemble the output of "arch" and/or "uname"?):

On an SGI 4D/30, this is what I get (hmm):
HOSTTYPE=iris4d
On a DECsystem 5500, this is what I get (ugh):
HOSTTYPE=decstation
On a Sun-4, this is what I get (hurray!):
HOSTTYPE=sun4


|> **** There is a (more-or-less) standard command:  /bin/uname!

Good point.  I have not looked at it for a while.  I rejected in the past.
Let's see what it gives from uname -s/uname -m:
On a 4D/30:
IRIX
IP12
On a DECsystem 5500:
ULTRIX
RISC
On a Sun-4/690:
SunOS
sun4m

These are not bad.  They are very inconsistent from vendor to vendor.
DEC is very general ("RISC" - isn't Alpha a "RISC" also?), Sun is
middle of the road (sun4m is too specific for user binaries, but it
can be fixed), while SGI is very specific (IP12 is too specific-
most user binaries will work on most, and at least a large subset,
of 4D systems).  They can't be used directly to construct a
reasonable architecture name ("IP12", for example, is both ugly
and too specific).  A long list of possibilities will have to be
maintained for some vendors (SGI).  However, "uname" may be the only
workable solution.  It was not available on all systems in the past,
or at least it didn't work well enough...

|>
|> Since IRIX 4.0, uname -s returns IRIX.  uname -m returns CPU type, which is
|> easy to parse into the appropriate bin if you want to separate R4K from R3K
|> binaries.  For now, we detect on uname -s, and, if IRIX is returned,
|> set the enviromental variable HOSTTYPE to "iris4d".  I can see the coming
|> need for "iris4d-r4k" or something like that, distinguished from
|> "iris4d-r3k".  (I know that backward compatibility is a curse, so I
|> won't belabor the point, but it's too bad that some of those nice
|> R4000 features can't be emulated somehow on the R3000's .....)

Another problem is what to do about different graphics consoles, and the
different binaries they sometimes need (at least, to be efficient).

|>
|> But, in general, it seems that uname -a returns all that is needed.  It
|> would be nice if SGI packaged up a "arch" and "arch -k" like replacement
|> for IRIX, and nailed down the necessary distinguishing names for all time.
|> But, there is no chance of getting DEC and IBM and HP and ... to all
|> agree to do that, so you have to use uname anyway!

Probably you are right.  Sigh.  However, I still maintain that this DOES
need to be done, and we have a definite requirement for it.

Anything that doesn't work so that the user's login shell can detect,
via .cshrc or whatever, the architecture, and respond appropriately, will
not work.  It has to work with a common home directory exported from a
fileserver to all the commonly used/available architectures, including,
but not limited to all architectures from: Sun, DEC, SGI, IBM, HP, Convex,
Cray, Amdahl UTS, ...(unameit)

|> Of course, there is also /bin/4d and friends, but that is clumsy and silly.

Agreed.  This isn't a general solution.

|>
|> Steve
|> --
|> Steve Couturie                      Voice:     [phone]
|> Chevron Information Technology Co.  FAX:       [phone]
|> P.O. Box  446                       Internet:  [e-mail]
|> La Habra, CA  90633-0446            UUCP:      ...!uunet!lhdsy1!shc

--
  Hugh LaMaster, M/S 233-9,     UUCP:      ames!lamaster
  NASA Ames Research Center     Internet:  [e-mail]
  Moffett Field, CA 94035-1000  Or:        [e-mail]
  Phone:  [phone]                     #include <usenet/std_disclaimer.h>