Alfred M. Szmidt wrote:
They are only non-portable across different operating systems (say
OpenBSD vs GNU). My point is that coreutils main goal is not to be
portable across various operating systems, if `uname -p' outputs
`unknown' on platforms that can't provide that info, then that is
If Hurd implements the interface to enable 'uname -p' then that
would certainly be a good thing in general. A win-win. But if it
does not then already at this time 'uname -p' is not really useful
to there.
But that isn't a good reason to make the option produce a error.
If you
Jim Meyering [EMAIL PROTECTED] writes:
BTW, I don't like the fact that the new %:z formats zero-fill by default,
when used with a wider field width, but I've left it as-is, for now.
Hmm, RFC 3339 requires the leading zero in +07:00. Some people like
+7 and they can have that by specifying a
While looking into this problem I noticed that Debian tried to disable
uname -p and -i, but they didn't do it quite right. For example:
$ /bin/uname -x
/bin/uname: invalid option -- x
Try `/bin/uname --help' for more information.
$ /bin/uname -p
Try `/bin/uname --help' for more
I like the fix. Though, changing the behaviour of `uname -a' just
cause some people have rebelled against it outputing `unknown' in some
places is quite silly; why not add such support to Linux and have it
output something useful!
Thanks Paul.
___
Paul Eggert [EMAIL PROTECTED] wrote:
2005-09-15 Paul Eggert [EMAIL PROTECTED]
* NEWS: uname -a no longer generates the -p and -i outputs if they
are unknown.
* doc/coreutils.texi (uname invocation): Document this.
* src/uname.c (usage): Document this.
(main):
Jim Meyering wrote:
Paul Eggert wrote:
2005-09-15 Paul Eggert [EMAIL PROTECTED]
* NEWS: uname -a no longer generates the -p and -i outputs if they
are unknown.
* doc/coreutils.texi (uname invocation): Document this.
* src/uname.c (usage): Document this.
(main):
