Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!cbmvax!snark!eric From: eric@snark.UUCP (Eric S. Raymond) Newsgroups: comp.unix.wizards Subject: `uname' survey results -- bad news, it's #@!!%@# useless Message-ID: Date: 26 Aug 88 08:33:43 GMT Organization: Eric Conspiracy Secret Laboratories Lines: 52 Some of you may recall that, a while back, I posted a request for uname output from many different machines. My hope was that it could be used for machines running System III or System V to extract things like the release level and processor type in some quasi-uniform way. Several hundred responses later, this hope has been rudely shattered. I am irresistably reminded of something one of Robert Heinlein's characters, a writer giving advice on how to sell manuscripts, once said. Roughly, it was: "You have to give editors something to piss on. Then they like the flavor better, so they buy it". The useless garbage reported by many of the sites that responded to the survey leads me to conclude that a great many UNIX vendors feel a sort of compulsion to urinate on the distribution somewhere, and that uname(2) is a favorite target. Perhaps this a form of corporate territorial marking. Common forms of brain-damage include: 1. Reporting the site name from the sysname (-s) field. This field is supposed to contain a generic OS name (UNIX, UTS, HP-UX). Even some AT&T machines (including my 3B1) make this mistake. 2. Non-support of the -m option (Masscomp RTU) or returning something that ain't nohow a processor type (SCO XENIX, many versions of which return '3' for some utterly inexplicable reason). 3. Total confusion in the version and release fields (-r and -v options). The 'release' field should contain the AT&T release level (1.x, 2.x, 3.x) and the version field is reserved for vendor-specific release info. Naturally, many vendors invert the two. Others report bizarre internal release-number formats (or even release dates) in the -r field. In at least one class of systems (older 68K and 80286 XENIXes) the porting people blithely decided to 'improve' uname's output to something that looks like a list of shell assignments. This complicates life wonderfully for portable autoconfiguration scripts. The nodename field (-n) is about the only thing almost everyone seems to get right, though some sites do report it empty. And uuname -l is more reliable for that purpose (XENIXes and perhaps some other systems extract uname -n's output from /etc/systemid rather than a kernel ID area via uname(2)). The upshot of all this is that uname is effectively useless. It would be nice if the vendors were to fix their messes but it's too late in the game for that to make a lot of practical difference. My autoconfiguration tools certainly won't be able to use uname. -- Eric S. Raymond (the mad mastermind of TMN-Netnews) UUCP: ...!{uunet,att,rutgers}!snark!eric = eric@snark.UUCP Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718