bug#16100: Bug in uname command

[Eric Blake]

forcemerge 14388 16100
thanks

On 12/10/2013 02:54 AM, Vishwas Dhankhar wrote:
> Hi,
> 
> Man page of uname command states that uname options:
> 
> -r, --kernel-release print the kernel release
> -v, --kernel-version print the kernel version
> 
> But I got the following result while using these options:
> 
> inlc7921> uname -r
> 2.6.16.60-0.58.1.3835.0.PTF.638363-smp
> 
> inlc7921> uname -v
> #1 SMP Wed Dec 2 12:27:56 UTC 2009
> 
> This seems a little opposite to what man page suggests. Please do take a
> look.

Thanks for the report.  However, this is turning into a FAQ; see
debbugs.gnu.org/14388 for the last discussion on the issue (we are
accurately returning what the kernel sticks in the struct used by the
uname(2) syscall; changing things would require a kernel change and not
something we can effect here; about the best we could do is a doc update
to make it clear that we really return whatever random strings the
kernel tells us even if those strings aren't "release" and "version" in
the sense you are expecting).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#16100: Bug in uname command

[Vishwas Dhankhar]

Hi,

Man page of uname command states that uname options:

-r, --kernel-release print the kernel release
-v, --kernel-version print the kernel version

But I got the following result while using these options:

inlc7921> uname -r
2.6.16.60-0.58.1.3835.0.PTF.638363-smp

inlc7921> uname -v
#1 SMP Wed Dec 2 12:27:56 UTC 2009

This seems a little opposite to what man page suggests. Please do take a
look.

bug#14388: Bug in uname command - reg...

[Bob Proulx]

Linda Walsh wrote:
> Bob Proulx wrote:
> >   $ uname -r
> >   3.2.0-4-amd64
> >   $ uname -v
> >   #1 SMP Debian 3.2.35-2
>
> From that -- it looks quite a bit like it describing version information.
> On mine, I have
> uname -r=3.9.0-Isht-Van
> 
> With Isht-Van being my localversion name
> The uname-v has:
> #6 SMP PREEMPT Wed May 8 17:28:40 PDT 2013
> Compile#, options date not sure why debians is different --- 3.2.35-2?
> 
> That's odd looking.

IBM AIX 3.5 returns information like this:

  $ uname -a
  AIX localhost 3 5 00CD7EAF4C00

  $ uname -r
  3

  $ uname -v
  5

HP-UX 11.31 will say something like this:

  $ uname -a
  HP-UX localhost B.11.31 U ia64 3682977672 unlimited-user license

  $ uname -r
  B.11.31

  $ uname -v
  U

Solaris 5.9:

  $ uname -a
  SunOS localhost 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Fire-15000

  $ uname -r
  5.9

  $ uname -v
  Generic_112233-12

I don't have access to a variety of machines these days so the above
is cutting and pasting from reports sent in that I found on the web.
I may have something slightly wrong in the above.  But it should still
be illustrative that every system interprets what to do with the
fields differently.

> It looks like they are a bit backwards -- but I think I would agree with
> Bob's assessment that it can't be something that is fixed since there
> are tons of programs (including programs IN THE KERNEL (to load modules))
> that use the 'release' to get the linux-version info...
> 
> *doh!*

Yes.  D'oh!  Which is why it isn't as useful as people think it might be.

> > Really the only portable way to use uname(1) is to call it first to
> > see which system name it returns and then after knowing the system
> > type then call it again with whatever options make sense on that
> > system.
>
>   Which is a bit like saying you need an interpreter that's
> system specific to pick out what is relevant.  That's special! ;->

Yes.  That is exactly what I am saying! :-)

Here is some live code from a script designed to run in a an
environment with all of the above.  This isn't general purpose and was
written to work exactly for the cases I needed it to work.  For
example for AIX I would have needed to have it combine -r and -v
together to get to 3.5 but for me knowing "aix" was good enough so I
stopped there.  I am just posting this to give an exapmle of the type
of system specific tests that are needed.  I am sure that if this
script were live working today that it would have variations for
current systems.

Bob

os=unknown
mach=unknown
uname=$(uname)
if [ $? -ne 0 ] || [ -z "$uname" ]; then
  echo "Error: Could not run 'uname'" 1>&2
  exit 1
fi
case $uname in
AIX)
  os=aix
  mach=rs6000
  ;;
HP-UX)
  case $(uname -m) in
  9000/*)
case $(uname -r) in
  ?.10.*) mach=hppa1.1 ;;
  *)  mach=hppa2.0 ;;
esac
;;
  *) mach=$(uname -m) ;;
  esac
  case $(uname -r) in
?.10.*)  os=hpux10 ;;
*) os=hpux$(uname -r | sed 's/^[AB]\.//') ;;
  esac
  ;;
Linux)
  os=gnulinux
  mach=$(uname -m)
  ;;
esac

bug#14388: Bug in uname command - reg...

[Linda Walsh]

Bob Proulx wrote:

> 
>   $ uname -r
>   3.2.0-4-amd64
> 
>   $ uname -v
>   #1 SMP Debian 3.2.35-2
---
I get something similiar the above, but that isn't the way
the kernel terminology -- despite the fact that use "uname-r" to search for the
kernel-version of modules
to use.

but 3=VERSION
2=PATCHLEVEL
0=SUBLEVEL
-4- = EXTRAVERSION
-amd64=LOCALVERSION

>From that -- it looks quite a bit like it describing version information.
On mine, I have
uname -r=3.9.0-Isht-Van

With Isht-Van being my localversion name
The uname-v has:
#6 SMP PREEMPT Wed May 8 17:28:40 PDT 2013
Compile#, options date not sure why debians is different --- 3.2.35-2?

That's odd looking.

It looks like they are a bit backwards -- but I think I would agree with
Bob's assessment that it can't be something that is fixed since there
are tons of programs (including programs IN THE KERNEL (to load modules))
that use the 'release' to get the linux-version info...

*doh!*


> 
> Really the only portable way to use uname(1) is to call it first to
> see which system name it returns and then after knowing the system
> type then call it again with whatever options make sense on that
> system.
---
Which is a bit like saying you need an interpreter that's
system specific to pick out what is relevant.  That's special! ;->

bug#14388: Bug in uname command - reg...

[Bob Proulx]

tag 14388 + moreinfo notabug
thanks

vevek venkatesan wrote:
>   In uname command In feel that there is a bug with -r and -v
> options which I describe as follows,
> 
> uname -r -> it should show the release of kernel
> uname -v -> it should show the version of kernel as per your manual page,
> but it is showing vice-versa of each.

Thank you for the report.  However the uname(1) command simply calls
the uname(2) system call.  It then reports what the kernel has stored
there.  It is a very old command having been around a very long time.
I don't think there is a bug there.

But you did not report the information that you are seeing.  If you
would be so kind as to report what you are seeing then perhaps we
would be able to know what is happening for you.  Since you didn't
tell us what you are seeing there isn't any way for us to know one way
or the other.  When reporting bugs it is necessary to show us what it
is doing for you.

In any case, here is a sample from my system.  This is the correct
output for my system.  Note that on other systems the values stored by
the kernel can be quite a bit different.  Especially on HP-UX and on
IBM AIX the output may be quite different!

  $ uname -r
  3.2.0-4-amd64

  $ uname -v
  #1 SMP Debian 3.2.35-2

Really the only portable way to use uname(1) is to call it first to
see which system name it returns and then after knowing the system
type then call it again with whatever options make sense on that
system.

Bob

bug#14388: Bug in uname command - reg...

[vevek venkatesan]

Hi Team,
  In uname command In feel that there is a bug with -r and -v
options which I describe as follows,

uname -r -> it should show the release of kernel
uname -v -> it should show the version of kernel as per your manual page,
but it is showing vice-versa of each.

Thanks & Regards,
- Vevek V

bug#7991: bug in uname (?)

[Eric Blake]

[re-adding the list]

On 02/05/2011 06:23 PM, Noel Kuntze wrote:
>> Look at 'man 2 uname'.  On Linux, the uname.release version contains a
>> numeric string.  The uname.version field is not documented as to it's
>> contents, but POSIX merely requires that release and version together
>> identify the operating system kernel.  As confusing as it may be, this
>> behavior is a kernel choice, and coreutils uname(1) has no control over
>> it.  Coreutils is accurately reporting what the kernel told it.
>>
> 
> Hi,
> 
> OK, i understood that.
> However although i run several different Linuxes i didn't use uname on
> any other than Debian.
> To "fix" this bug, one should really talk to the developers of the
> different distributions.

The different Linux distros all use the same uname(2) behavior of the
kernel.  You only need patch the kernel to swap those two fields, but
given historical compatibility, you have a very hard battle in front of
you for getting such a patch to be approved.

You're better off learning to live with the fields as currently defined
by the kernel, in spite of what you feel is an apparent naming confusion.

> This "bug" (i'll call it "bug" in the future, because "weird behaviour
> of the Kernel" is just too long) nearly got me a worse mark (we wrote a
> test about Debian Linux and the last task was to write down the kernel
> version).

Again, it's not a bug in coreutils, but a feature of your kernel's
uname(2) implementation.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#7991: bug in uname (?)

[Bob Proulx]

Noel Kuntze wrote:
> It seems to me that the options for uname, more precise, -v and -r have
> been interchanged.

The uname program dates back to the days of yore before we had refined
networking to the mature state that it is now.  It is really a
terrible interface.  Although we often use 'uname -a' to identify
systems it isn't out of love but simple practicality that there isn't
much better available.

If you collected the output of uname with various options on every
different system you could find you would have quite a collection of
random output!  At that point you would understand the problem.

The only portable use of uname is without arguments.  To use it
portably you can only really use it first to figure out which system
you are on and then follow that up with subsequent calls with system
specific options.  I often do this type of thing in scripts:

case $(uname) in
  HP-UX)
case $(uname -m) in
  9000/*)
case $(getconf CPU_VERSION) in
  528) mach=hppa1.1 ;;
  532) mach=hppa2.0 ;;
  768) mach=ia64 ;;
esac
;;
  *) mach=$(uname -m) ;;
esac
sys=hpux$(uname -r | sed 's/^[AB]\.//')
;;
  Linux)
sys=gnulinux
mach=$(uname -m)
;;
  AIX)
sys=aix
mach=rs6000
...
;;
esac

That is just an example.  Such as for AIX I would need to do more but
I didn't want to keep going with the example.

Bob

bug#7991: bug in uname (?)

[Eric Blake]

On 02/05/2011 01:31 PM, Noel Kuntze wrote:
> Hi,
> 
> It seems to me that the options for uname, more precise, -v and -r have
> been interchanged.

Thanks for the report.  However, this is not a bug.

> 
> Extract from the shell:
> 
> thermi@debian:~$ uname -v
> #1 SMP Thu Jan 27 00:28:05 UTC 2011
> thermi@debian:~$ uname -r
> 2.6.26-2-686

Look at 'man 2 uname'.  On Linux, the uname.release version contains a
numeric string.  The uname.version field is not documented as to it's
contents, but POSIX merely requires that release and version together
identify the operating system kernel.  As confusing as it may be, this
behavior is a kernel choice, and coreutils uname(1) has no control over
it.  Coreutils is accurately reporting what the kernel told it.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#7991: bug in uname (?)

[Noel Kuntze]

Hi,

It seems to me that the options for uname, more precise, -v and -r have
been interchanged.

Extract from the shell:

thermi@debian:~$ uname -v
#1 SMP Thu Jan 27 00:28:05 UTC 2011
thermi@debian:~$ uname -r
2.6.26-2-686

sincerely yours,

Noel Kuntze


Virus checked by G Data AntiVirus
Version: AVA 21.4667 dated 05.02.2011
Virus news: www.antiviruslab.com

RE: Bug in uname

[Walter Coole]

Thanks for maintaining a less-than-glorious, but useful utility.

I did check to make sure I was getting the expected version of uname:

which uname
/bin/uname

, but attempting to repeat the symptom got proper behavior!??:

uname -a
Linux cloudy 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT
2008 x86_64 x86_64 x86_64 GNU/Linux

A look at my history shows the command I originally used:
uname -a
uname: extra operand `-a'
Try `uname --help' for more information.

"Oh goody, identical commands, different behavior..."

cat | od -c
uname -a

000   u   n   a   m   e 342 200 223   a  \n  \n
014

It appears that the web page I cut-n-pasted from was rendered using a
UTF8 character (0xE28093) that just happens to look like a hyphen on my
terminal.

Nevermind :-)

Sorry about the .sig; it's the burden that comes of working for a
financial company.
Further sorry about the false alarm.
Walter


-Original Message-
From: Eric Blake [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 08, 2008 7:31 PM
To: Walter Coole
Cc: bug-coreutils@gnu.org
Subject: Re: Bug in uname

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Walter Coole on 12/8/2008 1:28 PM:
> uname -a
> 
> uname: extra operand `-a'

Thanks for the report.  Are you sure you don't have any aliases or shell
functions interfering?  Depending on your shell, 'which uname' or 'type
uname' will tell you.

...


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in uname

[Philip Rowlands]

On Mon, 8 Dec 2008, Eric Blake wrote:


The information contained in this e-mail may be privileged and/or


Sending mail from an account that adds a disclaimer longer than the body
of your message is considered poor netiquette.  This disclaimer is
unenforceable on a publicly archived mailing list, but some people refuse
to reply on principle.


Hi Eric,

I agree these disclaimers can be annoying, but there's no clue to the 
sender that "bug-coreutils@gnu.org" represents a publically archived 
mailing list. I'm not sure there's even an implied license to copy and 
re-publish the text of this email, although _I_ know that's what MHonArc 
will do on http://lists.gnu.org/



Cheers,
Phil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in uname

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Walter Coole on 12/8/2008 1:28 PM:
> uname -a
> 
> uname: extra operand `-a'

Thanks for the report.  Are you sure you don't have any aliases or shell
functions interfering?  Depending on your shell, 'which uname' or 'type
uname' will tell you.

By the way, the latest stable version is 6.12, and 7.0 is also available
for test.

> The information contained in this e-mail may be privileged and/or

Sending mail from an account that adds a disclaimer longer than the body
of your message is considered poor netiquette.  This disclaimer is
unenforceable on a publicly archived mailing list, but some people refuse
to reply on principle.  Therefore, you are better off sending mail from a
different email account.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk95oQACgkQ84KuGfSFAYAGuACgtlCspPQ53sPVWoGxmgvjAzSG
HSQAnjyA+vq8QPsGWBdFtGcKIS9fbbnX
=vkiV
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Bug in uname

[Walter Coole]

Uname isn't recognizing the -a option.

 

uname -a

uname: extra operand `-a'

Try `uname --help' for more information.

But

uname --help

Usage: uname [OPTION]...

Print certain system information.  With no OPTION, same as -s.

 

  -a, --allprint all information, in the following
order,

 except omit -p and -i if unknown:

  -s, --kernel-nameprint the kernel name

  -n, --nodename   print the network node hostname

  -r, --kernel-release print the kernel release

  -v, --kernel-version print the kernel version

  -m, --machineprint the machine hardware name

  -p, --processor  print the processor type or "unknown"

  -i, --hardware-platform  print the hardware platform or "unknown"

  -o, --operating-system   print the operating system

  --help display this help and exit

  --version  output version information and exit

 

Report bugs to .

Fortunately, --all works fine.

 

HTH,

Walter Coole

 

Aperio Group, LLC

Three Harbor Drive Suite 315

Sausalito, CA 94965

(415)339-4308 Direct

(415)339-4301 Fax

www.aperiogroup.com  

 

Aperio v. [Latin] to make clear, to reveal the truth

The information contained in this e-mail may be privileged and/or
confidential, and is intended only for the use of the person to whom it
is addressed. If you are not the named addressee (or such recipient's
employee or agent), you should not disseminate, distribute, alter or
copy this e-mail. Please notify the sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your
system. E-mail transmissions cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message, which may arise during or as a result of
e-mail transmission. Communication of any portfolio changes, cash
additions or withdrawals must always be confirmed or verified by verbal
and/or hard copy version. In compliance with regulatory requirements,
all messages sent to or from this server are archived and may be read by
someone other than the recipient. This message is provided for
information purposes and has been obtained from sources which we believe
to be reliable, but we do not guarantee its accuracy or completeness and
it should not be construed as a solicitation or offer to buy or sell any
securities or related financial instruments in any jurisdiction. Aperio
Group LLC provides neither tax nor legal advice to its clients, and all
investors are strongly urged to consult with their legal and tax
advisors regarding any potential investment or strategy.

 

___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

RE: Bug in uname

[Walter Coole]

Oops, I should have mentioned:

uname --version

uname (GNU coreutils) 6.10

Copyright (C) 2008 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by David MacKenzie.

 

Walter

 

From: Walter Coole 
Sent: Monday, December 08, 2008 12:28 PM
To: 'bug-coreutils@gnu.org'
Subject: Bug in uname

 

Uname isn't recognizing the -a option.

 

uname -a

uname: extra operand `-a'

Try `uname --help' for more information.

But

uname --help

Usage: uname [OPTION]...

Print certain system information.  With no OPTION, same as -s.

 

  -a, --allprint all information, in the following
order,

 except omit -p and -i if unknown:

  -s, --kernel-nameprint the kernel name

  -n, --nodename   print the network node hostname

  -r, --kernel-release print the kernel release

  -v, --kernel-version print the kernel version

  -m, --machineprint the machine hardware name

  -p, --processor  print the processor type or "unknown"

  -i, --hardware-platform  print the hardware platform or "unknown"

  -o, --operating-system   print the operating system

  --help display this help and exit

  --version  output version information and exit

 

Report bugs to .

Fortunately, --all works fine.

 

HTH,

Walter Coole

 

Aperio Group, LLC

Three Harbor Drive Suite 315

Sausalito, CA 94965

(415)339-4308 Direct

(415)339-4301 Fax

www.aperiogroup.com

 

Aperio v. [Latin] to make clear, to reveal the truth

The information contained in this e-mail may be privileged and/or
confidential, and is intended only for the use of the person to whom it
is addressed. If you are not the named addressee (or such recipient's
employee or agent), you should not disseminate, distribute, alter or
copy this e-mail. Please notify the sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your
system. E-mail transmissions cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender,
therefore, does not accept liability for any errors or omissions in the
contents of this message, which may arise during or as a result of
e-mail transmission. Communication of any portfolio changes, cash
additions or withdrawals must always be confirmed or verified by verbal
and/or hard copy version. In compliance with regulatory requirements,
all messages sent to or from this server are archived and may be read by
someone other than the recipient. This message is provided for
information purposes and has been obtained from sources which we believe
to be reliable, but we do not guarantee its accuracy or completeness and
it should not be construed as a solicitation or offer to buy or sell any
securities or related financial instruments in any jurisdiction. Aperio
Group LLC provides neither tax nor legal advice to its clients, and all
investors are strongly urged to consult with their legal and tax
advisors regarding any potential investment or strategy.

 

___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Bob Proulx]

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): Implement this.
> 
> I like it.
> Thanks for doing that.

Very good.  I like it too.

Thanks
Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Jim Meyering]

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): Implement this.

I like it.
Thanks for doing that.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Alfred M\. Szmidt]

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.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Paul Eggert]

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" <[EMAIL PROTECTED]> 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  <[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): Implement this.

Index: NEWS
===
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.310
diff -p -u -r1.310 NEWS
--- NEWS14 Sep 2005 06:57:35 -  1.310
+++ NEWS15 Sep 2005 19:55:38 -
@@ -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 -  1.282
+++ doc/coreutils.texi  15 Sep 2005 19:55:41 -
@@ -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 -  1.66
+++ src/uname.c 15 Sep 2005 19:55:41 -
@@ -118,7 +118,8 @@ usage (int status)
   fputs (_("\
 Print certain system information.  With no OPTION, same as -s.\n\
 \n\
-  -a, --allprint all information, in the following order:\n\
+  -a, --allprint all information, in the following order,\n\
+ except omit -p and -i if unknown:\n\
   -s, --kernel-nameprint 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, --machineprint 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)

Re: Possible bug in uname command

[Alfred M\. Szmidt]

   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 are not concerned about portability across systems and are
   only concerned about GNU Hurd then it would seem that whether an
   option is available or not on another system should not be a
   concern.

I'm concerned about both.  If a option works in GNU uname on GNU then
that same option should work (i.e. not report an error) on non-GNU
platforms.  --author in ls doesn't work (it shows the group, not
st_author) on GNU/Linux for example, or any of the BSDs, but it would
just be crazy to make it produce an error on those platforms.

   On the other hand I am concerned with portability across different
   systems.  And even in the case that I were using it semi-badly I
   think this would not be serious breakage.

If that is the case, why not just make `uname -p' (and for any other
non-POSIX options) produce an error if POSIXLY_CORRECT is defined?


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Bob Proulx]

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
> fine.

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.

If you are not concerned about portability across systems and are only
concerned about GNU Hurd then it would seem that whether an option is
available or not on another system should not be a concern.

On the other hand I am concerned with portability across different
systems.  And even in the case that I were using it semi-badly I think
this would not be serious breakage.

  case $(uname -z) in # intentionally using bad -z option here
foo)  echo foo ;;
bar)  echo bar ;;
*)  echo unknown uname output handler ;;
  esac

In that case:

  uname: invalid option -- z
  Try `uname --help' for more information.
  unknown uname output handler

That does not seem so bad.  A little noise to prod the author that the
option is not supported and should be handled more appropriately to be
portable to different systems.

In a more than semi-bad case:

  case $(uname -z) in # intentionally using bad -z option here
foo)  echo foo ;;
bar)  echo bar ;;
unknown)  echo unknown uname output handler ;;
  esac

That would break as shown here.

  uname: invalid option -- z
  Try `uname --help' for more information.

But I think it is bad to code in the unknown case here as in this
example.  Probably not going to be really fatal.  But already a
problem today for me to program across systems because already most
systems I work with do not implement -p.  I would need something like
this:

  case $(uname -p 2>/dev/null) in
sparc)  echo sparc ;;
*) echo unknown uname output handler ;;
  esac

That should work fine.  At least as well as it does today.

In any case, my goal with my suggestion was only that if something is
not going to be functional and will only serve to intice a lot of bug
reports from users reporting that it is not functional then I think it
is better not to provide it at all and avoid the complaints.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Alfred M\. Szmidt]

   >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 that I said "either".

Noted, sorry that I missed it.

   Does Hurd support the interface to supply 'uname -p' information?
   The implication from reading this is your statement is that it does
   not.  In which case 'uname -p' on GNU Hurd is not useful either.

It doesn't work currently, but there are no reasons why one couldn't
add such support.

   Because basically when dealing with a command as non-portable as
   uname you should take these differences into consideration now
   already.

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
fine.

Cheers.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Bob Proulx]

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.

Notice that I said "either".

Does Hurd support the interface to supply 'uname -p' information?  The
implication from reading this is your statement is that it does not.
In which case 'uname -p' on GNU Hurd is not useful either.

> How about those options get disabled if POSIXLY_CORRECT is defined
> instead?  That makes sense, and doesn't break scripts.

Can you give an example of scripts that would use 'uname -p' and why
they are not already broken now?  Because basically when dealing with
a command as non-portable as uname you should take these differences
into consideration now already.  The only portable way to use uname is
without any options and then work from there after you know what
system you are on.  Look at config.guess for lots of examples of uname
issues.  Basically uname is awful.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Alfred M\. Szmidt]

   > >  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 mad... :(

   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.

How about those options get disabled if POSIXLY_CORRECT is defined
instead?  That makes sense, and doesn't break scripts.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Alfred M\. Szmidt]

   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

Re: Possible bug in uname command

[Bob Proulx]

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 like mad... :(

I don't think it will break scripts because legacy operating systems
don't support those options either.  Therefore most people looking at
'uname -p' output will already be broken on many platforms.  And on
platforms where it works it will continue to work.

  [EMAIL PROTECTED]:~$ /bin/uname -p
  /bin/uname: illegal option -- p
  usage: uname [-amnrsvil] [-S nodename]

Neither does Debian.  They disable the option because of the user
complaints.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Eric Blake]

>> 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 option.
> 
> But that will break scripts like mad... :(

Since POSIX doesn't document -p or -i, they are already non-portable
options.  But you do have a point that just deleting the options
may have far-reaching effects...

--
Eric Blake




___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Alfred M\. Szmidt]

   > 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 option.

But that will break scripts like mad... :(


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Bob Proulx]

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 invalid option.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Paul Eggert]

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
Linux versions.

For example, on a Solaris 10 (sparc) box, uname -a might output this:

SunOS otter 5.10 Generic_118822-11 sun4u sparc SUNW,Sun-Fire-V440 Solaris

The "sparc" and "SUNW,Sun-Fire-V440" correspond to the --processor and
--hardware-platform options that are unknown on Linux boxes.
/proc/cpuinfo probably would say just "cpu family : 27" or something
like that, which would be a pain to map to an actual name like
"sparc".  (Or perhaps uname could just output the "27"; doesn't sound
that helpful, though.)  And the "SUNW,Sun-Fire-V440" is more of a
motherboard concept than a CPU concept; is there a
/proc/motherboardinfo in Linux?

Maybe if some Linux whiz wanted to maintain it as a nice dropin
library.  But personally I'd rather just have the Linux folks support
this stuff in their system calls; that's where it belongs.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Eric Blake]

-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 kernel folks.

What about parsing /proc/cpuinfo, on machines that have that?  (Cygwin
falls into the same camp as linux, where this information is in
/proc/cpuinfo, but not available from any easy system call.)

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDJ5OH84KuGfSFAYARApHEAJ9rYI3q3EF8bVO/G5W7mDDvRrVUSwCfYUBL
xTX4M5DVIUxlQbTNz+tfqf8=
=18S5
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Possible bug in uname command

[Paul Eggert]

"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: Linux doesn't support the relevant sysinfo
(Solaris-style) or sysctl (BSD-style) system calls.  Perhaps you can
report the problem to the Linux kernel folks.

In the meantime I installed the following documentation patch to
coreutils.

2005-09-13  Paul Eggert  <[EMAIL PROTECTED]>

* doc/coreutils.texi (uname invocation): Mention that Linux outputs
"unknown" for -i and -p.

--- doc/coreutils.texi  13 Sep 2005 22:07:58 -  1.280
+++ doc/coreutils.texi  13 Sep 2005 23:01:59 -  1.282
@@ -12225,6 +12225,8 @@ Print all of the below information.
 @cindex platform, hardware
 Print the hardware platform name
 (sometimes called the hardware implementation).
+Print @samp{unknown} if the kernel does not make this information
+easily available, as is the case with Linux kernels.
 
 @item -m
 @itemx --machine
@@ -12252,6 +12254,8 @@ Print the network node hostname.
 @cindex host processor type
 Print the processor type (sometimes called the instruction set
 architecture or ISA).
+Print @samp{unknown} if the kernel does not make this information
+easily available, as is the case with Linux kernels.
 
 @item -o
 @itemx --operating-system


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Possible bug in uname command

[Asif Iqbal, Trumboo]

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 mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in uname on Darwin 7.8.0

[Jim Meyering]

Geert Jan van Oldenborgh <[EMAIL PROTECTED]> wrote:
> a while ago I installed the very useful coreutils on my iMac.  However,
> when I tried to upgrade my free software collection with fink it
> refused.  The reason turned out to be a bew uname from coreutils, which
> did not recognize the processor:
>
> [srikandi] [13:13] /sw% /usr/local/bin/uname --version
> uname (coreutils) 5.0

That's fixed in a newer version:

  ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.bz2

___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

bug in uname on Darwin 7.8.0

[Geert Jan van Oldenborgh]

Dear Madam, Sir,
a while ago I installed the very useful coreutils on my iMac.  However, 
when I tried to upgrade my free software collection with fink it 
refused.  The reason turned out to be a bew uname from coreutils, which 
did not recognize the processor:

[srikandi] [13:13] /sw% /usr/local/bin/uname --version
uname (coreutils) 5.0
Written by David MacKenzie.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.
[srikandi] [12:43] /sw% /usr/local/bin/uname -p
unknown
[srikandi] [13:13] /sw% /usr/bin/uname -p
powerpc

If I can do anything to help fix this bug please let me know.
Greetings from Gouda, Holland,
Geert jan van Oldenborgh
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils