Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!rpi!uupsi!cmcl2!lanl!jlg From: jlg@lanl.gov (Jim Giles) Newsgroups: comp.arch Subject: UNIX mind-set (was: How wrong is MS-DOS?) Message-ID: <11267@lanl.gov> Date: 13 Jan 91 07:40:51 GMT References: Organization: Los Alamos Natl Lab, Los Alamos, N.M. Lines: 70 I changed the name because the subject is no longer about UNIX vs. MS-DOS, but about the UNIX fragment-and-pipe approach to programming. In fact, many specific MS-DOS utilities suffer in ways similar to what I'm complaining about in UNIX. Also, I still don't think this newsgroup is the right venue for this discussion. I looked back at comp.sys.misc (and remembered why I unsubscribed). That doesn't look like the place. Someone suggested alt.humor - an interesting idea, but still probably not approporiate. Any suggestions? Maybe others would think that comp.sys.misc _is_ appropriate. From article , by spot@CS.CMU.EDU (Scott Draves): > [...] > Your use of UNIX must be very different from mine (and others'), or > you are talking about programming and not interactive use. Both. But all too often programming _is_ done with pipes, etc.. > [...] > I do *not* want to write a program every time I want to search a file > for a word. [...] Quite so. In my case, well over 90% of such searches are followed by an edit of the file in the neighborhood of the found word. So - over 90% of such searches I do are from within an editor - which should have such searches built-in. Much of the rest of the time, what I want the search to do is show me something of the context of each place where the pattern matches - usually, one line isn't enough of that context (so, in this case, I often end up using the editor again). So, the remaining few times I need a grep-like functionality are to make up for the lack of such a feature in tools like ls. Here is where I make my once or twice a month use of grep. I should be able to say something like 'ls -owner jblow' and get a list of all files in the directory belonging to joe blow. I _could_ write a shell script to do this (use awk to extract the owner field from an 'ls -l' sequence, then grep for 'jblow'). What I usually end up doing, though, is writing 'ls -l | grep jblow' - which has the unfortunate habit of also listing files whos names contain 'jblow'. Using grep this way doesn't exemplify the strength of grep - it simply (almost) covers a weakness in ls. A production quality ls would have the capability to filter any of the fields of a file description in generally useful ways. For example, what about 'ls -before 1/1/90' to list all files created before Jan. first 1990? Try to do _that_ with grep. > [...] > If you are saying you would never write production code in csh using > all those utilities, then I agree. And so will (nearly?) everyone > else. That would be slow and gross. Then you agree that a version of ls which does the above should _not_ be written as a shell script? Indeed, the functionality of filtering on the creation dates would probably be easier from within a program than for a script. In any case, utilities should be written to the same standards of quality and efficiency as and other production code and, by your own statement, should not be written as scripts. Note: the use of ls as an example in this note is just that: an example. The same kind of argument could be applied to many other tools (like other system inquiry stuff: ps, who, etc.) - which should all contain built-in capabilities to filter the information they produce. I don't want to get into a long discussion about specific properties of ls like this one going on about grep. The grep utility itself I chose as a specific example of a whole class of UNIX utilities whose functionality should be contained in appropriate other programs (like dd, tr, etc.). J. Giles