[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible bug in uname command
From: |
Paul Eggert |
Subject: |
Re: Possible bug in uname command |
Date: |
Thu, 15 Sep 2005 13:05:29 -0700 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
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 information.
I checked the Debian bug database, and found that this is bug 193170
(see the mail from Kalle Olavi Niemitalo dated 2005-04-30).
I'll CC: this message to Debian, since I just installed a patch to
fix this bug along with everything else (please see below).
"Alfred M\. Szmidt" <address@hidden> writes:
> How about those [uname -p and -i] options get disabled if
> POSIXLY_CORRECT is defined instead?
I'd rather not do that, since we want to minimize the effects of
POSIXLY_CORRECT. POSIX does not require that these options be
disabled (or enabled, for that matter), so POSIXLY_CORRECT should not
affect uname's behavior when presented with those options.
I think you and Bob Proulx are both right, to some extent. GNU/Linux
users have rebelled against having "uname -a" output "unknown" all the
time, so we should fix this. However, it's certainly OK if "uname -p"
outputs "unknown".
Bob Proulx's idea of reporting -p and -i as invalid options if the
values are unknown would be a bit tricky, since in general we don't
know they're invalid unless we try to get the values.
So, instead, I propose that uname -a not output the -i and -p
information if it is unavailable. That'll make uname -a output harder
to parse, but it's already impossible to parse portably anyway, so
it's no big deal. It does address the issue that Debian rebelled
over. And it won't break any scripts in practice (unless they're
unportable or broken anyway).
I installed the following patch to implement this. Comments are
welcome. I wish the problem would go away, but it won't....
2005-09-15 Paul Eggert <address@hidden>
* 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): Implement this.
Index: NEWS
===================================================================
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.310
diff -p -u -r1.310 NEWS
--- NEWS 14 Sep 2005 06:57:35 -0000 1.310
+++ NEWS 15 Sep 2005 19:55:38 -0000
@@ -210,6 +210,8 @@ GNU coreutils NEWS
stat -f's default output format has been changed to output this size as well.
stat -f recognizes file systems of type XFS and JFS
+ uname -a no longer generates the -p and -i outputs if they are unknown.
+
* Major changes in release 5.3.0 (2005-01-08) [unstable]
** Bug fixes
Index: doc/coreutils.texi
===================================================================
RCS file: /fetish/cu/doc/coreutils.texi,v
retrieving revision 1.282
diff -p -u -r1.282 coreutils.texi
--- doc/coreutils.texi 13 Sep 2005 23:01:59 -0000 1.282
+++ doc/coreutils.texi 15 Sep 2005 19:55:41 -0000
@@ -12214,7 +12214,8 @@ The program accepts the following option
@itemx --all
@opindex -a
@opindex --all
-Print all of the below information.
+Print all of the below information, except omit the processor type
+and the hardware platform name if they are unknown.
@item -i
@itemx --hardware-platform
Index: src/uname.c
===================================================================
RCS file: /fetish/cu/src/uname.c,v
retrieving revision 1.66
diff -p -u -r1.66 uname.c
--- src/uname.c 14 May 2005 07:58:37 -0000 1.66
+++ src/uname.c 15 Sep 2005 19:55:41 -0000
@@ -118,7 +118,8 @@ usage (int status)
fputs (_("\
Print certain system information. With no OPTION, same as -s.\n\
\n\
- -a, --all print all information, in the following order:\n\
+ -a, --all print all information, in the following order,\n\
+ except omit -p and -i if unknown:\n\
-s, --kernel-name print the kernel name\n\
-n, --nodename print the network node hostname\n\
-r, --kernel-release print the kernel release\n\
@@ -126,8 +127,8 @@ Print certain system information. With
fputs (_("\
-v, --kernel-version print the kernel version\n\
-m, --machine print the machine hardware name\n\
- -p, --processor print the processor type\n\
- -i, --hardware-platform print the hardware platform\n\
+ -p, --processor print the processor type or \"unknown\"\n\
+ -i, --hardware-platform print the hardware platform or \"unknown\"\n\
-o, --operating-system print the operating system\n\
"), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
@@ -172,7 +173,7 @@ main (int argc, char **argv)
switch (c)
{
case 'a':
- toprint = -1;
+ toprint = UINT_MAX;
break;
case 's':
@@ -286,7 +287,8 @@ main (int argc, char **argv)
# endif
}
#endif
- print_element (element);
+ if (! (toprint == UINT_MAX && element == unknown))
+ print_element (element);
}
if (toprint & PRINT_HARDWARE_PLATFORM)
@@ -310,7 +312,8 @@ main (int argc, char **argv)
element = hardware_platform;
}
#endif
- print_element (element);
+ if (! (toprint == UINT_MAX && element == unknown))
+ print_element (element);
}
if (toprint & PRINT_OPERATING_SYSTEM)
- Re: Possible bug in uname command, (continued)
- Re: Possible bug in uname command, Eric Blake, 2005/09/13
- Re: Possible bug in uname command, Paul Eggert, 2005/09/14
- Re: Possible bug in uname command, Bob Proulx, 2005/09/14
- Re: Possible bug in uname command, Alfred M\. Szmidt, 2005/09/14
- Re: Possible bug in uname command, Bob Proulx, 2005/09/14
- Re: Possible bug in uname command, Alfred M\. Szmidt, 2005/09/14
- Re: Possible bug in uname command, Bob Proulx, 2005/09/14
- Re: Possible bug in uname command, Alfred M\. Szmidt, 2005/09/14
- Re: Possible bug in uname command, Bob Proulx, 2005/09/15
- Re: Possible bug in uname command, Alfred M\. Szmidt, 2005/09/15
- Re: Possible bug in uname command,
Paul Eggert <=
- Re: Possible bug in uname command, Alfred M\. Szmidt, 2005/09/15
- Re: Possible bug in uname command, Jim Meyering, 2005/09/15
- Re: Possible bug in uname command, Bob Proulx, 2005/09/16
Re: Possible bug in uname command, Eric Blake, 2005/09/14