a properly built ksh93 should match /usr/bin/uname -i by getting the value from
sysinfo(SI_PLATFORM,buf,size)
check the configuration from within ksh93 with the getconf builtin
getconf -t | grep PLATFORM
which should produce something like
PLATFORM SOL 1 SI 513 F SUNW,SPARC-Enterprise
re-check the sysinfo() value (this makes a direct call to sysinfo())
getconf 'SI(513)'
the builtin uname implementation calls astconf("PLATFORM",0,0) to get the value
this references the same table listed by 'getconf -t'
we use astconf(string,0,0) to mitigate the vendor/architecture differences
between
{ confstr(2) sysconf(2) pathconf(2) sysinfo(2) uname(2) <limits.h> <float.h>
etc. }
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
On Thu, 27 Mar 2008 13:17:20 PDT Richard L. Hamilton wrote:
> On a Sun Blade 2000,
> $ /usr/bin/uname -i
> SUNW,Sun-Blade-1000
> (a Sun Blade 2000 is nearly indistinguishable from a 1000)
> The dtksh builtin gives the hostid (in hex) instead; the ksh93 builtin (if
> enabled
> by prefixing PATH with /usr/ast/bin) gives "unknown", and its help says
> $ uname --help
> [...]
> -i, --implementation|platform|hardware-platform
> The hardware implementation; this is --host-id on some
> systems.
> [...]
> For the heck of it, /usr/gnu/bin/uname -i and /opt/sfw/bin/uname -i
> (both the GNU version) give SUNW,Sun-Blade-1000.
> The difference between /usr/bin/uname and dtksh has been like that for a
> very long time; ok (well not, but it's not a new problem). But:
> * which is right?
> * which should ksh93 be giving instead of "unknown"? (I think the need to
> answer
> that drives the need to answer the former a little further)
> SUSv3 is no help; it doesn't define -i for uname although it seems to permit
> options
> over and above those it does define. See
> http://www.opengroup.org/onlinepubs/000095399/utilities/uname.html
