uname (GNU sh-utils) 1.16

[Peter Hans van den Muijzenberg]

Hi,

Well, originally this was going to be a real bug-report, since according to
uname 1.15 my Amiga ran without processor, but 1.16, asreleased through
GeekGadgets for the Amiga, does report a 68020, which just leaves some
questions on the design and implementations of uname.

The documentation for uname 1.16 says:


> uname: Print system information
> ... 
>    The program accepts the following options.  Also see Common options.
> -a
> --all
>      Print all of the below information.
> -m
> --machine
>      Print the machine (hardware) type.
> -n
> --nodename
>      Print the machine's network node hostname.
> -p
> --processor
>      Print the machine's processor type
> -r
> --release
>      Print the operating system release.
> -s
> --sysname
>      Print the operating system name.
> -v
>      Print the operating system version.

And basically that's all we get. There's no history, which could direct us
to a base version, there's no definition of any of the terms, nothing.

Machine (hardware) type: I could interpret this as the box: Amiga CD32/SX32,
or like the current uname, as the line of processors: m86k. As you can see
even the second interpretation would benefit from standardization since I
could write "M680x0", "Motorola 68xxx",etc.

Nodename: What about a machine not hanging in any network? Leave blank?
"LocalHost"? Not to mention a gateway, hanging into multiple networks?

Processor: Fairly clear, although it leaves open what to do if one processor
is supposed to be compatibel with another: 68020 is fairly clear, but
should we merely report 80468, or would that be "Intel 80486" to
distinguish is from clones, even though those perfrom virtually identical?
I do have a small problem with this one: Where do I leave coprocessors, even
if they are from the same processor line? Should I get "68020 68881" or
maybe "68020/68881", even though this combination is quite common, or
should that be "68020/no-68881" in the opposite case, to merely indicate
the exception? But wat's an exception on one ardware line may be the rule
on another. 
(I wonder how many people would have expected that option to be "--cpu".)

Release and version: I'll take them together because the basic problem here
is:
Are we talking about the values in a <version>.<release>.<build> tuple? If
we are version would probably be <version>, and release would probably, but
not certain, be <version>.<release>. But the version I have uses version to
indicate the release <version>.<release>, and release to indicate the
distribution <break>.<compatible> distribution.
BTW, shouldn't the -v option have a --sysversion keyword? (Personally, I'd
have used --osversion --osrelease --osname, but since the less descriptive
"sys" is already in use that may nolonger be an option.) 

Sysname: The obvious things: Should it say OS at the end of AmigaOS? Should
it include the number of a breaking change in the distribution, espacially
i a complete redesign occurred?


Why do all go on about all this? (Well, I need a way to determine the
absence of coprocessors. (-:) Because GNU releases have a configuration
script system sitting atop uname. Part of this is config.guess, which
creates a canonical (if equally undocumented) form for a machine
description from the output of uname, guessing those parts uname doesn't
report.

That really doesn't make much sense, does it? If GNU needs an output in
canonical form from uname, then the GNU version of uname (which may or may
not be the only version, since the doc doesn't tell us the history) ought
to have a --canon option. After all, if it isn't available in uname, which
could be hand-crafted for every model if need be, how likely is it that
config.guess, which is general for the whole STEPPE (where HURD's of GNU
live), can make it available anyhow? 


Well, that's it. For now I'll hack uname to report what I need for furter
configuration, but I'd like to know what real solution will come out of
this.

BFN,
-- 
               Peter Hans van den Muijzenberg
                        address@hidden
                   address@hidden