> I also don't buy that it "breaks scripts".
> 
> read the POSIX documentation on it -- the fields are user-defined,
> and _MAY CONTAIN SPACES_.  if scripts don't allow for that, they're
> broken (and, frankly, anybody who writes scripts for distribution, and
> doesn't deal with quoting issues properly, has no right to complain).

Complain about the configure scripts that are used by most GNU tools
then.  Including eg. GNATS, Emacs & bash to name a few.

> here's the output of uname with each of the possible flags except -a:
> 
> 212 [pain] cgd % uname -m
> i386
> 213 [pain] cgd % uname -n
> pain.cs.berkeley.edu
> 214 [pain] cgd % uname -r
> NetBSD 0.9B

This is the one that breaks them.  And what is the use of repeating the
OS name when you ask about the _revision_ of the system?

> 215 [pain] cgd % uname -s
> NetBSD
> 216 [pain] cgd % uname -v
> NetBSD 0.9B (PAIN) #119: Fri May 20 02:44:25 PDT 1994     cgd@sun-lamp.cs.berkeley.edu:
/e/users/cgd/trees/ren/sys/arch/i386/compile/PAIN

This one is typically not used in configuration scripts etc., but is
still plain ugly...  Why break with what every other version on Unix
has been using?  Why not use eg. the BSD release date or the configuration
build like we used to have here?

> by POSIX (and common sense), none of those is unreasonable.  nobody
> should be using uname -v for anything anyway, as it has and always
> will describe version of the currently-running kernel.

The scripts in question use the -m, -s and -r info, not -v.  But the
output from -v (and thus -a) is still ugly and to a certain degree
unreadable.

> if people are using scripts for configuration, then they should
> probably be using -m, -r, and -s.  given that, the only "possibly
> objectionable" one is -r, which is legal by POSIX, and, for any
> reasonable configuration script, is no harder to deal with than "0.9B"
> for instance.

Sure.  But what is wrong with trying to at least keep up a semblance
of compatibility with most other Unix versions that are out there? Just
that POSIX _allows_ spaces doesn't neccecarily mean we _have_ to have
them in there, does it?

I won't complain (much) more about the output of "uname -v", but I'd
really like "uname -r" to just give "0.9B"...

Or perhaps it does...

Thorsten
--
Thorsten Lockert  | postmaster@bbb.no   |
Postbox 435       | hostmaster@bbb.no   |  Universe, n.:
N-5001 Bergen     | tholo@bbb.no        |          The problem.
Norway            | tholo@sigmasoft.com |

------------------------------------------------------------------------------