Date: Thu, 16 Mar 1995 22:49:15 +0200 From: Mark Murray <mark@grondar.za> To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> Cc: mark@grondar.za (Mark Murray), FreeBSD-current@FreeBSD.org Subject: Re: ps and grep Message-ID: <199503162049.WAA12129@grunt.grondar.za>
next in thread | raw e-mail | index | archive | help
> 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 :-> :-> :-> > 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?. 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. 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?). > 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???? > 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. > 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"? 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). > 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??!) > 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?) -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503162049.WAA12129>