From lyndon@orthanc.com  Sun Apr 14 00:45:39 1996
Received: from multivac.orthanc.com (root@multivac.orthanc.com [206.12.238.2])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA02878
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 14 Apr 1996 00:45:36 -0700 (PDT)
Received: from orodruin.orthanc.com (root@orodruin.orthanc.com [206.12.238.3]) by multivac.orthanc.com (8.7.3/8.7.3) with ESMTP id AAA03778 for <FreeBSD-gnats-submit@freebsd.org>; Sun, 14 Apr 1996 00:45:31 -0700 (PDT)
Received: (from root@localhost) by orodruin.orthanc.com (8.7.5/8.7.3) id AAA01503; Sun, 14 Apr 1996 00:45:29 -0700 (PDT)
Message-Id: <199604140745.AAA01503@orodruin.orthanc.com>
Date: Sun, 14 Apr 1996 00:45:29 -0700 (PDT)
From: Lyndon Nerenberg <lyndon@orthanc.com>
Reply-To: lyndon@orthanc.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: uname.1 and uname.c disagree about display ordering
X-Send-Pr-Version: 3.2

>Number:         1139
>Category:       bin
>Synopsis:       uname.1 and uname.c disagree about display ordering
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Apr 14 00:50:02 PDT 1996
>Closed-Date:    Wed Sep 18 11:33:15 PDT 1996
>Last-Modified:  Wed Sep 18 11:34:38 PDT 1996
>Originator:     Lyndon Nerenberg
>Release:        FreeBSD 2.2-CURRENT i386
>Organization:
Orthanc Systems
>Environment:

>Description:

uname(1) claims '-a' is the same as '-m -n -r -s -v' however the
code displays as '-n -r -s -v -m'. 

>How-To-Repeat:

>Fix:
	
The following patch to /usr/src/usr.bin/uname/uname.c rearranges
the flag checks to match the man page.

===================================================================
RCS file: uname.c,v
retrieving revision 1.1
diff -c -r1.1 uname.c
*** uname.c	1996/04/14 07:35:40	1.1
--- uname.c	1996/04/14 07:36:54
***************
*** 102,107 ****
--- 102,116 ----
  
  	prefix = "";
  
+ 	if (flags & MFLAG) {
+ 		mib[0] = CTL_HW;
+ 		mib[1] = HW_MACHINE;
+ 		len = sizeof(buf);
+ 		if (sysctl(mib, 2, &buf, &len, NULL, 0) == -1)
+ 			err(1, "sysctl");
+ 		(void)printf("%s%.*s", prefix, len, buf);
+ 		prefix = " ";
+ 	}
  	if (flags & SFLAG) {
  		mib[0] = CTL_KERN;
  		mib[1] = KERN_OSTYPE;
***************
*** 138,152 ****
  		for (p = buf, tlen = len; tlen--; ++p)
  			if (*p == '\n' || *p == '\t')
  				*p = ' ';
- 		(void)printf("%s%.*s", prefix, len, buf);
- 		prefix = " ";
- 	}
- 	if (flags & MFLAG) {
- 		mib[0] = CTL_HW;
- 		mib[1] = HW_MACHINE;
- 		len = sizeof(buf);
- 		if (sysctl(mib, 2, &buf, &len, NULL, 0) == -1)
- 			err(1, "sysctl");
  		(void)printf("%s%.*s", prefix, len, buf);
  		prefix = " ";
  	}
--- 147,152 ----
>Release-Note:
>Audit-Trail:

From: "Marc G. Fournier" <scrappy@ki.net>
To: Lyndon Nerenberg <lyndon@orthanc.com>
Cc: FreeBSD-gnats-submit@freebsd.org,
        GNATS Management <gnats@freefall.freebsd.org>,
        freebsd-bugs@freefall.freebsd.org
Subject: Re: bin/1139: uname.1 and uname.c disagree about display ordering
Date: Sun, 14 Apr 1996 04:40:52 -0400 (EDT)

 On Sun, 14 Apr 1996, Lyndon Nerenberg wrote:
 
 > >Description:
 >
 > uname(1) claims '-a' is the same as '-m -n -r -s -v' however the
 > code displays as '-n -r -s -v -m'.
 >
 
 	I may be missing the point here, but option ordering doesn't
 seem to make any difference:
 
 freebsd# uname -n -r -s -v -m
 FreeBSD freebsd.ki.net 2.2-CURRENT FreeBSD 2.2-CURRENT #6: Sun Apr 14 02:51:52 EDT 1996     scrappy@freebsd.ki.net:/usr/src/sys/compile/freebsd  i386
 
 freebsd# uname -m -n -r -s -v
 FreeBSD freebsd.ki.net 2.2-CURRENT FreeBSD 2.2-CURRENT #6: Sun Apr 14 02:51:52 EDT 1996     scrappy@freebsd.ki.net:/usr/src/sys/compile/freebsd  i386
 
 freebsd# uname -a
 FreeBSD freebsd.ki.net 2.2-CURRENT FreeBSD 2.2-CURRENT #6: Sun Apr 14 02:51:52 EDT 1996     scrappy@freebsd.ki.net:/usr/src/sys/compile/freebsd  i386
 
 	The man page states:
 
      -a      Behave as though the options -m, -n, -r, -s, and -v were speci-
              fied.
 
 	It doesn't say in what order, just that it will behave as if all were
 specified.
 
 Marc G. Fournier                                  scrappy@ki.net
 Systems Administrator @ ki.net               scrappy@freebsd.org
 

From: Lyndon Nerenberg VE7TCP <lyndon@orthanc.com>
To: "Marc G. Fournier" <scrappy@ki.net>
Cc: freebsd-gnats-submit@freebsd.org, gnats@freefall.freebsd.org,
        freebsd-bugs@freebsd.org
Subject: Re: bin/1139: uname.1 and uname.c disagree about display ordering 
Date: Sun, 14 Apr 1996 13:39:34 -0700

 >>>>> "Marc" == Marc G Fournier <scrappy@ki.net> writes:
 
     Marc> 	I may be missing the point here, but option ordering
     Marc> doesn't seem to make any difference:
 
 Read the source and you'll see why.
 
     Marc>      -a Behave as though the options -m, -n, -r, -s, and -v
     Marc> were speci- fied.
 
     Marc> 	It doesn't say in what order, just that it will behave
     Marc> as if all were specified.
 
 True, but the implication (as I read it) is that things will come out
 in the documented order.
 
 Your comments point out another bug - the output should match the option
 ordering specified on the command line.
 
 --lyndon
 

From: "Marc G. Fournier" <scrappy@ki.net>
To: Lyndon Nerenberg VE7TCP <lyndon@orthanc.com>
Cc: freebsd-gnats-submit@freebsd.org, gnats@freefall.freebsd.org,
        freebsd-bugs@freebsd.org
Subject: Re: bin/1139: uname.1 and uname.c disagree about display ordering 
Date: Sun, 14 Apr 1996 17:23:14 -0400 (EDT)

 On Sun, 14 Apr 1996, Lyndon Nerenberg VE7TCP wrote:
 
 > >>>>> "Marc" == Marc G Fournier <scrappy@ki.net> writes:
 >
 >     Marc> 	I may be missing the point here, but option ordering
 >     Marc> doesn't seem to make any difference:
 >
 > Read the source and you'll see why.
 >
 	I have, and option ordering doesn't make any difference in the
 source code...unless I'm missing something you are seeing?
 
 >     Marc>      -a Behave as though the options -m, -n, -r, -s, and -v
 >     Marc> were speci- fied.
 >
 >     Marc> 	It doesn't say in what order, just that it will behave
 >     Marc> as if all were specified.
 >
 > True, but the implication (as I read it) is that things will come out
 > in the documented order.
 >
 	first off, how do you get it implied that the ordering of the
 output is determined by the ordering of the options from the man page?
 I've just read the man page twice more, and find no implication to this
 effect...
 
 	And, uname -a does behave as if options -m -n -r -s and -v are
 specifed:
 
 > uname -a
 FreeBSD ki.net 2.1-STABLE FreeBSD 2.1-STABLE #5: Tue Mar 26 14:40:09 EST 1996     scrappy@ki.net:/usr/src/sys/compile/kinet  i386
 > uname -m -n -r -s -v
 FreeBSD ki.net 2.1-STABLE FreeBSD 2.1-STABLE #5: Tue Mar 26 14:40:09 EST 1996     scrappy@ki.net:/usr/src/sys/compile/kinet  i386
 
 	Exact same ordering of the output regardless of which format
 I use...therefore, the man page is accurate to the operation of the program,
 IMHO.
 
 > Your comments point out another bug - the output should match the option
 > ordering specified on the command line.
 >
 	Why?  All your options are doing are turning on various flags.
 About the only way I could see of cleanly (reasonably cleanly, at least)
 accomplishing this would be to get rid of each of the "if(flags &..)"
 constructs and place them inside of the getopt() while loop, so as
 each flag came up, its appropriate output would be printed.
 
 	Not a bad idea, until you consider the instance where you try:
 
 	uname -m -z (oops, I missed the a and hit z)
 
 	As it is now, you will get an error and a usage message because
 of the z...having it output on a flag-by-flag basis would result in getting
 the output for -m and then the error/usage message, which kind of sounds
 messy to me.
 
 
 Marc G. Fournier                                  scrappy@ki.net
 Systems Administrator @ ki.net               scrappy@freebsd.org
 

From: Mike Pritchard <mpp>
To: lyndon@orthanc.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/1139: uname.1 and uname.c disagree about display ordering
Date: Mon, 15 Apr 1996 13:09:43 -0700 (PDT)

 Lyndon Nerenberg wrote:
 > 
 > >Description:
 > 
 > uname(1) claims '-a' is the same as '-m -n -r -s -v' however the
 > code displays as '-n -r -s -v -m'. 
 > 
 > >How-To-Repeat:
 > 
 > >Fix:
 > 	
 > The following patch to /usr/src/usr.bin/uname/uname.c rearranges
 > the flag checks to match the man page.
 
 If anything, the man page should be changed to match the code,
 not the other way around.  uname -a has worked this way for a long
 time, and changing its output now is not a good idea.
 -- 
 Mike Pritchard
 mpp@freebsd.org
 "Go that way.  Really fast.  If something gets in your way, turn"

From: Lyndon Nerenberg VE7TCP <lyndon@orthanc.com>
To: Mike Pritchard <mpp@freefall.freebsd.org>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/1139: uname.1 and uname.c disagree about display ordering 
Date: Mon, 15 Apr 1996 16:08:03 -0700

 If the man page is changed (instead of the code), it should also indicate
 that the command ignores the ordering of the flags and always spits the
 data out in a fixed order.
 
 --lyndon

From: Mike Pritchard <mpp>
To: lyndon@orthanc.com (Lyndon Nerenberg VE7TCP)
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/1139: uname.1 and uname.c disagree about display ordering
Date: Mon, 15 Apr 1996 17:24:51 -0700 (PDT)

 Lyndon Nerenberg VE7TCP wrote:
 > 
 > If the man page is changed (instead of the code), it should also indicate
 > that the command ignores the ordering of the flags and always spits the
 > data out in a fixed order.
 
 Looking at the man page shows that the flags described for "-a"
 are listed in alphabetical order, which seems perfectly reasonable
 to me.  Since most commands under FreeBSD ignore the order of 
 command line flags, I don't think adding something mentioning this fact 
 in the uname.1 man page really makes sense, since we would have to 
 modify a large number of other man pages to be consistent.
 
 I suggest we leave uname.1 as is.
 -- 
 Mike Pritchard
 mpp@freebsd.org
 "Go that way.  Really fast.  If something gets in your way, turn"
State-Changed-From-To: open->closed 
State-Changed-By: wosch 
State-Changed-When: Wed Sep 18 11:33:15 PDT 1996 
State-Changed-Why:  
Not a bug. 
>Unformatted:
