Date: Thu, 16 Mar 1995 12:12:44 -0800 (PST) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: mark@grondar.za (Mark Murray) Cc: FreeBSD-current@FreeBSD.org Subject: Re: ps and grep Message-ID: <199503162012.MAA16490@gndrsh.aac.dev.com> In-Reply-To: <199503161937.VAA07123@grunt.grondar.za> from "Mark Murray" at Mar 16, 95 09:37:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > It really pisses me off when you do ps | grep foo and foo isn't > > > > found because it's really long and ps truncates its output to fit > > > > the screen width so grep never sees it. > > > > > > Me too. I would also like to 'ps -gaux | less' and see _everything_. > > > > Looks like a religious issue... if you run a shell that has aliases > > one way to fix this is: > > OK, War of the roses it is! ;-) Okay, let me pull on my flame proof jumpsuite (used only for skydiving into areas with active volcanos) :-) :-) ... ... > A lot of UN*X tools behave differently when faced with an output that is not > the terminal. Take a look at "ls" vs "ls | cat". In each case, the output is > tailored to to most likely use of the utility; I would say it is more like a ``few'' tools behave this way, and IMHO it has been and always well be a mistake in a UN*X system to change the behavior of any tool based upon what type of fd the output is. 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. 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. > are you looking at the output > as formatted for human eyes, or formatted for some other processing? _I_ > think that the default output should assume that if stdout is the user's > terminal, then it should be truncated, if the output is redirected, let it > all hang out, and let the user figure out an alias to undo this if (s)he > so desires. 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!!!!!!!!! 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. I guess I'll have to start to type ``ps lax | colrm 80 | more'' until I can back patch my copy of ps. I guess is what I am saying is if you want to change ps, change it so that *all* knowledge of what the output fd looks like is gone and rip out the w and ww options. Let us go use pipes like god^h^h^hdmr meant them to be used! DOOR!... 5 left and cut.... Ready.. Set.. Go.. BOMB SHELLlllll.... Jumpers away... :-) :-) :-) -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503162012.MAA16490>