From owner-freebsd-current Thu Mar 16 13:39:34 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA28798 for current-outgoing; Thu, 16 Mar 1995 13:39:34 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA28792 for ; Thu, 16 Mar 1995 13:39:16 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id NAA16686; Thu, 16 Mar 1995 13:38:22 -0800 From: "Rodney W. Grimes" Message-Id: <199503162138.NAA16686@gndrsh.aac.dev.com> Subject: Re: ps and grep To: mark@grondar.za (Mark Murray) Date: Thu, 16 Mar 1995 13:38:22 -0800 (PST) Cc: FreeBSD-current@FreeBSD.org In-Reply-To: <199503162049.WAA12129@grunt.grondar.za> from "Mark Murray" at Mar 16, 95 10:49:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 7422 Sender: current-owner@FreeBSD.org Precedence: bulk > > > Okay, let me pull on my flame proof jumpsuite (used only for skydiving > > into areas with active volcanos) :-) :-) ... ... > > takes out megabuster-argument-breaking _freeze_-gun :-> :-> :-> Oh no... my jumpsuite is crackling into little pieces and I am finding it *very* hard to do free style with it frozen!!! >-< (stick man solo) 8-O > > Remeber one of the underlying concepts of Un*x is that a file is a file > > is a file, and all things are files. I have always found the behavior > > of ``ls | *'' to change behavior a bad idea. Okay, yea it makes it > > easier to do some things, but it also makes it harder to do others > > (like I have a directory with 200 files in it, I want to look at this > > directory in ls format, but piped to more so it does not scroll off > > my window. Well some one changed it so now I have to look at one > > column of output because that person was too lazy to do something > > more orthagonal like make a tool that split lines of words into > > lines with one word each on them.) Or perhaps always make ls output > > one file to a line and then use ls | column. Yea, I like that > > latter idea. Yea... ``ls | column | more'' does what I want. > > This may have been the original idea, but the paradigm changed. With > commands, the paradigm is now (well, what it is now??!) dead?. I guess that is one of the problems I am having, I am of the very old camp and still like the original ``paradigm'' since the changes to it have really just been ad hoc :-(. > If the > behaviour of ls were to change to a consistent output, never mind > what the _type_ of output is, there would be a MEGA-breakage, and a > HUGE outcry. I reckon, go with the flow. Let's keep consistent with > the current philosophy. Wasn't it BSD that changed the way ls worked by changing the output to be lines with mutliple files on it *if* the output was to a terminal. If I recall correctly V6 and V7 always output one file to a line. (Gee, I am getting old, I am starting to forgot all these things :-(). > I think it would be best to just keep this momentum going, and > let it happen. There may well be some diehard (sorry!) resistance, but > at least it converges with a known precedent (Sp?). Yep.. one diehard.. right here!! > > People wonder why the size of UNIX is getting so huge, it is becuase > > people have forgotten how to use small tools tuned to very specific > > jobs to make large tools. I wonder how many tools could be cut > > down to size by something like a VMS DCL language that knew how to > > build pipes for many common options. > > PUKE!! You call dcl small? When last did you look???? AHh.. well... V5.2 or so... and DCL itself is not that large, it is all the executables that it invokes. And I said something LIKE dcl, great progress was made in that direction when the getopt stuff happened in u*ix and eliminated 100's of private command line parsers. I would like to follow that to the next step. Just look at how simple it should be to replace the all too common: while (ch = getopt(blah) !=EOF) { switch(ch) { case 'flag': f_flag = 1; break; ... } } I think that this should be table/data driven like DCLTABLES.EXE (I don't like the fact DEC called it an EXE on bit, and would call it something like shelltable.dat). I don't think we should go as far as dec did with DCL, hell, you can make 80% of the system calls in VMS from DCL!!!! > > My argument is more along the lines that no tool should ever make > > any assumption about were it's output is going. And it should NOT change > > this behavior just becuase it is trying to be smart and *thinks* the output > > is going to a human. It can not and should not ever know this!!!!!!!!! > > But a lot _does_, by default. What I am suggesting, is that under the > appropriate circumstances, it should not. Okay, we have sighted ps, and ls knowing about the type of output. Just how long is this list *really* ? I get 434 programs from ``ls /bin /sbin /usr/bin /usr/sbin | wc''. Now just how many of them try to be smart about there input or output fd? > > It can not know if I am doing ``ps | grep foo'' or ``ps | more'', so > > why try to be smart about it, as this intelegence only causes someone > > else to have to be even smarter than it to get what they really want. > > > > If you make ps change behavior based upon it's type of output you are > > just propogating some of what are IMHO the grosses things about unix > > implementations we have today. > > Like what? "unix is growing" or "unix is a 'mature' operating system"? No that we have abondoned the file is a file is a file and all things are files paradigm and now a tty is a different kind of file than a pipe or a disk file. I'll will say that unix is growing, yes, we have more tools than ever, but we also have more tools than ever imbeded inside of other tools. It's getting kinda like my brother mechanical shop, there are so many tools I can't find the tool I need :-) > The reason unix is popular, is because it adapts to requirements. If this > is a requirement to the majority, unix will follow. if not, it will be > outvoted and die. DCL/VMX is popular amongst weenies because it is > dictatorial to the extreme, controlled by the Ultimate Vendor (tm) > and therefore not all-that-hacker-friendly (IMHO). Humm.. I agree that it is popular ``because it adapts to requirements'', but the reason it adopts is because the source code is out there being wacked on by 1000's instead of 10's or 100's as in something like VMS. I guess I'm a weenie then, but when it comes to 50GB transactional data bases running paperless wafer fabrication facilities with 24 x 7 uptime requirements you could't have paid me to even think about doing it on unix, for that matter I would still do it on VMS today. Hacker friendly, well, you have to know to BLISS and MACRO-11, then it is!!! And you have to submit really really good and complete SPR's with all the fixes and changes you want with at least 5 pages saying why this is a good change.. and then you have to fight them to get it in for the next 2 releases and then finally by the 3rd or 4th release something similiar to what you wanted finally gets in. > > I guess I'll have to start to type ``ps lax | colrm 80 | more'' until I > > can back patch my copy of ps. > > You shouldn't need to do this. All you should need is an alias to undor > the default behaviour (which I would hope is supported??!) Ohh.. so what *you* want to change in ps is make ww on by default and I use say W to turn it off. But only if the output is a not to a terminal, then I must use ww to get my wide output... *YUKO* > > > DOOR!... 5 left and cut.... Ready.. Set.. Go.. BOMB SHELLlllll.... > > Jumpers away... > > :-) :-) :-) > > (PS Rod, would you be interested in some pics of my 400th? (Coming at our > Easter Boogie) 1xTandem, with some fun and games thrown in?) We are probably the only 2 on the list that even knows what that was above, I was having a hard time remeber if it was you or not!! SURE! Glad to here your going to go make that 400th jump!! Humm.. tandem with fun and games. I've seen some strange ones (ever seen a rodeo'ed tandem instructor try to get his drogee out???) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD