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
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):
Eric Blake [EMAIL PROTECTED] writes:
What about parsing /proc/cpuinfo, on machines that have that?
That's been discussed, but it sounds like a can of worms. The
information doesn't map all that well to the uname output, and my
admittedly uninformed feeling is that it is not that standard among
Paul Eggert wrote:
That's been discussed, but it sounds like a can of worms.
I have often thought it would be better if on machines that could not
reasonably support those extra uname options that the options be
disabled entirely. Then instead of unknown the program would report
it as an
That's been discussed, but it sounds like a can of worms.
I have often thought it would be better if on machines that could
not reasonably support those extra uname options that the options
be disabled entirely. Then instead of unknown the program would
report it as an invalid
That's been discussed, but it sounds like a can of worms.
I have often thought it would be better if on machines that could
not reasonably support those extra uname options that the options
be disabled entirely. Then instead of unknown the program would
report it as an
Alfred M. Szmidt wrote:
I have often thought it would be better if on machines that could
not reasonably support those extra uname options that the options
be disabled entirely. Then instead of unknown the program would
report it as an invalid option.
But that will break scripts
Since POSIX doesn't document -p or -i, they are already non-portable
options.
GNU Coreutils isn't POSIX Coreutils.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
I have often thought it would be better if on machines that
could not reasonably support those extra uname options that
the options be disabled entirely. Then instead of unknown the
program would report it as an invalid option.
But that will break scripts like
Alfred M. Szmidt wrote:
I don't think it will break scripts because legacy operating
systems don't support those options either.
^^
If you consider GNU a legacy operating system, sure. Recall, GNU
coreutils is for GNU, not non-GNU systems.
I don't think it will break scripts because legacy operating
systems don't support those options either.
^^
If you consider GNU a legacy operating system, sure. Recall, GNU
coreutils is for GNU, not non-GNU systems.
Notice
Dear Sir,
There seems to be a possible bug in uname command on most versions of
the Linux system.
uname -p prints 'unknown' instead of the host processor name.
Please look into the matter.
Thanks and Regards,
Asif Iqbal Trumboo
___
Bug-coreutils
Asif Iqbal, Trumboo [EMAIL PROTECTED] writes:
There seems to be a possible bug in uname command on most versions of
the Linux system.
uname -p prints 'unknown' instead of the host processor name.
As I understand it, that is a deficiency in the Linux API rather than
a bug in coreutils proper
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As I understand it, that is a deficiency in the Linux API rather than
a bug in coreutils proper: Linux doesn't support the relevant sysinfo
(Solaris-style) or sysctl (BSD-style) system calls. Perhaps you can
report the problem to the Linux
18 matches
Mail list logo
