treingol@journey.att.com (01/10/91)
The System V systems I use run releases 3.1 and 3.2. They allow you to type "who -Hq" which doesn't really make sense. The 'H' flag is to print a header for the normal "who" output, and the 'q' flag is to change the output to use multiple columns. So the output of "who -Hq" looks like this; the header line is meaningless. NAME LINE TIME cgf denisede ayoung jjschuld oneillv eah dgeorge mhratko jportlan vbt mschuld fishere cgarbows ghager ehornich dave jadler cg rbalko kmccarth robbo gchung kfriedma ecronin mferguso gwm bonnieb jpittas wai raturner kr cvourtsi egoon seema mm patt rjones tchapman mreddy dandriol acs kch treingol # users=43 Is the SVR4 who command derived from BSD or SVR3? Tom Reingold AT&T att!journey!treingold Juniper Plaza, Route 9 treingold@journey.att.com Room 1A-133 (908) 577-5814 [work] Freehold, NJ 07728-3298 (908) 287-2345 [home]
paul@unhtel.uucp (Paul S. Sawyer) (01/10/91)
In article <9101091725.AA15013@ucbvax.Berkeley.EDU> treingol@journey.att.com writes: >The System V systems I use run releases 3.1 and 3.2. They allow you to >type "who -Hq" which doesn't really make sense. The 'H' flag is to >print a header for the normal "who" output, and the 'q' flag is to >change the output to use multiple columns. So the output of "who -Hq" >looks like this; the header line is meaningless. > >NAME LINE TIME >cgf denisede ayoung jjschuld oneillv eah dgeorge mhratko >jportlan vbt mschuld fishere cgarbows ghager ehornich dave >jadler cg rbalko kmccarth robbo gchung kfriedma ecronin >mferguso gwm bonnieb jpittas wai raturner kr cvourtsi >egoon seema mm patt rjones tchapman mreddy dandriol >acs kch treingol ># users=43 $ who -Hq argos jed lookout paul paul root # users=6 $ uname -rvm 2.1.2 1 3B15 From TFM (for who -q): ".... When this option is used, all other options are ignored." One of the few rewards for running a dinosaur? B-) -- Paul S. Sawyer {uunet,attmail}!unhtel!paul paul@unhtel.uucp UNH CIS - - Telecommunications and Network Services pss@unhd.unh.edu Durham, NH 03824-3523 VOX: +1 603 862 3262 FAX: +1 603 862 2030
gwyn@smoke.brl.mil (Doug Gwyn) (01/12/91)
In article <1991Jan10.130738.10194@unhtel.uucp> paul@unhtel.uucp (Paul S. Sawyer) writes: >$ who -Hq >argos jed lookout paul paul root ># users=6 Of course the actual bug is that "who" has no business being designed this way. If you want columnation, it is trivial (who|6, for example), as is a user count (who|wc). Building such functionality into the "who" command is so much against UNIX design principles that I have to wonder who could have approved such features.
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (01/12/91)
In article <14818@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >Of course the actual bug is that "who" has no business being designed >this way. If you want columnation, it is trivial (who|6, for example), >as is a user count (who|wc). Building such functionality into the >"who" command is so much against UNIX design principles that I have to >wonder who could have approved such features. The same guy who approved turning ls into the feeping creature that it is today, of course...and other stuff, as well. (Why does Berzerkeley ls have to act the way it does? Yuk. Having to say ls if the destination is a terminal, but ls -C if I want to pipe into, say, is nonintuitive at best.) -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "I smell a scientific fish." -- Chip Salzenberg
jfh@rpp386.cactus.org (John F Haugh II) (01/13/91)
In article <14818@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >Of course the actual bug is that "who" has no business being designed >this way. If you want columnation, it is trivial (who|6, for example), >as is a user count (who|wc). Building such functionality into the >"who" command is so much against UNIX design principles that I have to >wonder who could have approved such features. This makes the assumption that the initial design of "who" was perfect in the first place. It is clear (to me, at least) that an unadorned "who" should tell you exactly what it does. However, there are sufficient reasons for more or less information to be given. Why should I be forced to 1) write a new command (ala "users") or 2) use pipes (ala "who | cut -d' ' -f1 | pr -6 -l1) to get the same results as "who -q"? The real problem comes in when the information is presented in a form that requires special processing to be useful, as does the output of "who -q". That last line serves little use when contrasted against the purpose of the who command, which is "Lists who is on the system". Perhaps Doug is right - perhaps one command should have one narrowly defined purpose. On the other hand, what is preventing "users" from being a simple link to "who -q"? -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."
guy@auspex.auspex.com (Guy Harris) (01/13/91)
>(Why does Berzerkeley ls have to act the way it does? Yuk. Having to say ls >if the destination is a terminal, but ls -C if I want to pipe into, say, >is nonintuitive at best.) And since this is "comp.bugs.sys5", I note that S5R4's "ls" acts the way the BSD one does; having people add aliases/shell functions to force "-C" on, or wrapping a script around it with a different name to force "-C" on, or having it look at "argv[0]" and force "-C" on if invoked with the right name, might have been better. And when I say "force", I mean *FORCE*. There are times when I want a multi-column listing when "ls" is *not* going directly to the terminal, e.g. when piping it to a pager program.
sef@kithrup.COM (Sean Eric Fagan) (01/13/91)
In article <18896@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >Perhaps Doug is right - perhaps one command should have one narrowly >defined purpose. On the other hand, what is preventing "users" from >being a simple link to "who -q"? I was not aware that any version of *nix allowed links, hard or soft, to allow options to be specified. If you mean, as I suspect you do, that who examine argv[0] to see what it should do, well, I guess you're also advocating everything in /bin be the same program, that only examines argv[0] to find out what it should do. Right? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
henry@zoo.toronto.edu (Henry Spencer) (01/13/91)
In article <18896@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >... Why should I be forced to... use pipes (ala "who | >cut -d' ' -f1 | pr -6 -l1) to get the same results as "who -q"? Because they are the simplest and cheapest way to get the desired results? I don't care how easy it was to add the "-q" option, it was a waste of the programmer's time. A shell program using pipes could have been written in seconds, solving the problem without messing around with "who". There seems to be a pervasive delusion that the only two ways things can be done are (a) add every conceivable option to the C program or (b) force the user to type long sequences using pipes. The correct approach, when such functionality is often used, is to package it up in a system-supplied shell file. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
kre@cs.mu.OZ.AU (Robert Elz) (01/14/91)
henry@zoo.toronto.edu (Henry Spencer) writes: >In article <18896@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) >writes: >>... Why should I be forced to... use pipes (ala "who | cut -d' .... >I don't care how easy it was to add the "-q" option, it was a waste of the >programmer's time. A shell program using pipes could have been written in >seconds, solving the problem without messing around with "who". This is sheer religious fervour taken to extremes ... the simply fact is that "who" is one of the most baroque commands in unix, if it had originally been more like (say) "ls", where "who" gave a simple list of users, and "who -l" gave similar output to the traditional "who", no-one would even think of complaining about it - but because it wasn't originally done that way, it's apparently heresy to suggest that anything be changed. Now I've never seen a "who" with a "-q" option, so I can't comment on how well the change was thought out (comments here make me suspect not well at all, but that's hearsay only), but the question of whether a change should be made at all is simply not suitably answered by "never". kre
jfh@rpp386.cactus.org (John F Haugh II) (01/14/91)
In article <1991Jan13.004843.18650@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <18896@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >>... Why should I be forced to... use pipes (ala "who | >>cut -d' ' -f1 | pr -6 -l1) to get the same results as "who -q"? > >Because they are the simplest and cheapest way to get the desired results? How can you possibly say that? The amount of machine overhead in the above case is several times greater than "who -q". In which sense is it "the simplest and cheapest way"? >I don't care how easy it was to add the "-q" option, it was a waste of the >programmer's time. A shell program using pipes could have been written in >seconds, solving the problem without messing around with "who". Sure, I managed to write that little blurb in about 5 seconds. Most of that time was spent considering if I wanted to sort the list (ala BSD "users" command) or not. However, once you add yet another program you have to add all of the support that goes into having yet another file to hold the source, yet another file to hold the documentation, yet another file to hold any test cases, etc. >There seems to be a pervasive delusion that the only two ways things can >be done are (a) add every conceivable option to the C program or (b) force >the user to type long sequences using pipes. The correct approach, when >such functionality is often used, is to package it up in a system-supplied >shell file. Straw man. No one is suggesting that "every conceivable option" be added to the "who" command. Given that BSD provides "users" and System V provides "who -q", there is clearly a desire to have the functionality described. Adding the second command ("users") only increases the amount of code which must be maintained with no resultant benefits in usablity or performance. fork() and exec() are neither free nor even cheap - shell scripts are just not the right answer. The "-q" option involves a very small code change and an additional paragraph on a manpage which already has the heading "Lists who is on the system". The BSD manpage begins "compact list of users who are on the system". Which is clearer? Two commands on two different pages, or one command with one additional option? -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."
tim@delluk.uucp (Tim Wright) (01/14/91)
In <1991Jan12.215911.20701@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In article <18896@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >>Perhaps Doug is right - perhaps one command should have one narrowly >>defined purpose. On the other hand, what is preventing "users" from >>being a simple link to "who -q"? >I was not aware that any version of *nix allowed links, hard or soft, to >allow options to be specified. 'uptime' and 'w' under 4.1BSD are the same program. Even more fun write a little C program to allow you to run any program with a different argv array. Try running the v7 /bin/mail under 4.1BSD. with no argv[0] - the result: % xa /bin/mail Puke! % Honest !! (I'm not sure of the punctuation - it was a while ago). >If you mean, as I suspect you do, that who examine argv[0] to see what it >should do, well, I guess you're also advocating everything in /bin be the >same program, that only examines argv[0] to find out what it should do. >Right? No, but once upon a time in a land before shared libraries it was pretty reasonable to throw graphics (e.g. X-style) programs together into one large monolithic one - that is if you wanted any disk space left :-) Tim -- Tim Wright, Dell Computer Corp. (UK) | Email address Bracknell, Berkshire, RG12 1RW | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
geoff@zoo.toronto.edu (Geoffrey Collyer) (01/14/91)
> fork() and exec() are neither free nor even cheap - shell scripts are > just not the right answer. If memory serves, a PDP-11/70, a Sun 3/180 and a Sun 4/280 (to pick random examples :-), all with SMD disks, fork and exec at about the same rate. Given the increases over time in SMD disk, CPU and memory speeds, this is inexcusable, and means that relative to hardware capabilities, fork and exec are getting more expensive over time. On reflection, we could account for about 10% of the CPU time taken by the Sun 3 fork. (I don't have the numbers at hand; I believe we measured SunOS 3.5 and 4.0 [with and without shared libraries] where possible.) If vendors would fix their kernels to stop squandering the available hardware resources, users could use kernel facilities as they were intended to be used, rather than twisting and contorting every application ``because fork and exec are too expensive''. Fix the problem in one place. (One is reminded of the current internet fad for whapping some combination of authentication and encryption into every protocol rather than solving the problem in TCP, once, but that's a flame for another time.) -- Geoff Collyer utzoo!geoff, zoo.toronto.edu!geoff
guy@auspex.auspex.com (Guy Harris) (01/15/91)
>There seems to be a pervasive delusion that the only two ways things can >be done are (a) add every conceivable option to the C program or (b) force >the user to type long sequences using pipes. The correct approach, when >such functionality is often used, is to package it up in a system-supplied >shell file. I suspect a lot of the reason why people think only in terms of those options is that the "system-supplied shell file" is often *not* supplied by the system. This isn't an argument against the *principle* of not shoveling options into every command; however, it *is* an argument against one of the mindset of the vendors of the systems (hardware or software vendors, and probably any organization that puts out a version of UNIX is guilty of this - including your favorite one, for most values of "you"). I don't know if the problem can be fixed by better education, or if the notion of packaging such functionality into a shell file isn't likely to be picked up by most vendors, for whatever reason - which might well be an argument against the idea in *practice*.
henry@zoo.toronto.edu (Henry Spencer) (01/15/91)
In article <18899@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >>Because they are the simplest and cheapest way to get the desired results? > >How can you possibly say that? The amount of machine overhead in the >above case is several times greater than "who -q". In which sense is >it "the simplest and cheapest way"? Add up the costs of writing the C code, the costs of maintaining it, the costs of enhancing it to add the next round of silly "features", and so forth. Now consider how many times per second "who" gets run, and how critical its performance is -- i.e., not very many and not very. The optimization is not worth the price. >... fork() and exec() are neither free nor even cheap - shell >scripts are just not the right answer. Odd; we've found that shell scripts are the right answer for an enormous range of applications. "ls" is a shell script on utzoo (it invokes the Sun ls with the -1 option). The question is not whether fork() and exec() are free -- obviously not -- or cheap -- thanks to manufacturer stupidity and greed, often they aren't -- but whether they are cheap *enough*. The answer is usually "yes". Incidentally, it turns out that one can often rewrite Berkeley or AT&T C programs as shell files and find that they run *faster*. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
woods@eci386.uucp (Greg A. Woods) (01/16/91)
In article <18899@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > In article <1991Jan13.004843.18650@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > >In article <18896@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > >>... Why should I be forced to... use pipes (ala "who | > >>cut -d' ' -f1 | pr -6 -l1) to get the same results as "who -q"? > > > >Because they are the simplest and cheapest way to get the desired results? > > How can you possibly say that? The amount of machine overhead in the > above case is several times greater than "who -q". In which sense is > it "the simplest and cheapest way"? To follow up on what Geoff already said, one should also note the cost of a C programmer far exceeds even the accumulated cost of the few seconds it takes every user to get the exact output he or she wants each time by typing a short script, and the extra milliseconds required to execute the script. BTW, the original script was somewhat simpler than the ugly SysV example given above. Besides, the user who learns to use tools will save ever so much more time in the future. Yes, lots of thought, or should I say experience, needs to go into defining the set of available tools and their options. One thing which makes me mad is the way vendors blindly grab the source from AT&T, compile it, and sell it. What ever happened to the feedback channel to AT&T? Why aren't the good things in Research UNIX getting out? Maybe this is why people blindly fall in love with BSD. However, don't, especially in this day and age, equate "simple and cheap" with "the least amount of memory and CPU". We have to have a reasonable balance, sure. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
lml@cbnews.att.com (L. Mark Larsen) (01/18/91)
The original message complained that (in SVR3) 'who -Hq' gave both the (in this case, meaningless) header and the output of the -q option. It was later pointed out by someone running SVR2 that this was apparently something broken going into SVR3. I just thought I would mention that the bug introduced in SVR3 is still in SVR4 (at least, the one we have running on our 3b2). cheers, lml@atlas.att.com
bt455s39@uhccux.uhcc.Hawaii.Edu (Carmen Hardina) (01/21/91)
In article <9101091725.AA15013@ucbvax.Berkeley.EDU> treingol@journey.att.com (Tom Reingold) writes: >The System V systems I use run releases 3.1 and 3.2. They allow you to >type "who -Hq" which doesn't really make sense. The 'H' flag is to >print a header for the normal "who" output, and the 'q' flag is to >change the output to use multiple columns. So the output of "who -Hq" >looks like this; the header line is meaningless. > >NAME LINE TIME >cgf denisede ayoung jjschuld oneillv eah dgeorge mhratko >jportlan vbt mschuld fishere cgarbows ghager ehornich dave >jadler cg rbalko kmccarth robbo gchung kfriedma ecronin >mferguso gwm bonnieb jpittas wai raturner kr cvourtsi >egoon seema mm patt rjones tchapman mreddy dandriol >acs kch treingol ># users=43 > >Is the SVR4 who command derived from BSD or SVR3? > >Tom Reingold [....] Under SCO XENIX System V, a "who -Hq" produces the following output. carmen carmen carmen # users=3 I don't know about SVR4, but I do belive that the XENIX binary is derived from SVR2 source. It's a bug in the code, not functionality. If the q option worked properly, the ability to also specify the H option (or any other, for that matter) would "make sense". The XENIX man page states the following. -q This is a quick who, displaying only the names and the number of users currently logged on. When this option is used, all other options are ignored. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Which vendors port of SVR3 are you using? --Carmen