Date: Sun, 14 Apr 1996 17:23:14 -0400 (EDT) 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 Message-ID: <Pine.BSI.3.92.960414170923.22378C-100000@ki.net> In-Reply-To: <199604142039.NAA10243@multivac.orthanc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.92.960414170923.22378C-100000>