James C. McPherson wrote:

/usr/bin/iAPX286
/usr/bin/i286
/usr/bin/i860
/usr/bin/pdp11
/usr/bin/u3b
/usr/bin/u3b2
/usr/bin/u3b5
/usr/bin/u3b15
/usr/bin/vax
/usr/bin/u370


Can you tell me, with a straight face - and proof- that
Solaris 2.6 or later will even run on *any* of the above
processors?

No, of course not. Who mentioned Solaris at all? These commands
aren't there for Solaris, they are there so that generic
scripts can work out what platform they are runing on, Solaris
or not.

If I wrote a portable configure script which contained something
like:

if [ vax ]; then
        do vaxy setup
else if [ u3b ]; then
        do AT&T setup
else if [ sun ]; then
        do Solaris setup
endif

it would work unchanged on all those architectures. Take out the
vax and u3b commands and it will then crash when run on Solaris.

This is an generic Unix application issue, not a Solaris one.

They're unlikely to be used in modern applications, true, but
were used a lot in legacy generic tools. It just seems pointless
to break those for no good reason. Why not just make all the
above binaries a link to /usr/bin/false?


The above processor truth types are all links to machid,
which contains this comment in $SRC/cmd/machid/machid.c:

The key item is in the middle:

   strictly for backwards compatibility.

we seem to have discarded that concept these days, which is a pity.

cheers

Steve

--
Steve McKinty           Architect - Sun Cluster Geographic Edition
Grenoble Engineering Centre, France:    http://blogs.sun.com/SC/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
opensolaris-arc mailing list
[email protected]

Reply via email to