Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!yale!cmcl2!lanl!jlg From: jlg@lanl.gov (Jim Giles) Newsgroups: comp.arch Subject: Re: UNIX mind-set (was: How wrong is MS-DOS?) Message-ID: <11305@lanl.gov> Date: 13 Jan 91 22:05:23 GMT References: <1991Jan13.113349.21937@ims.alaska.edu> Organization: Los Alamos Natl Lab, Los Alamos, N.M. Lines: 71 From article <1991Jan13.113349.21937@ims.alaska.edu>, by floyd@ims.alaska.edu (Floyd Davidson): > [...] > The advantage of UNIX is that tools are trivial to the point of > doing just one basic thing. As a result each user can easily > build larger tools to do *anything*. [...] By this logic, ls doesn't fit the paradigm. I can (on any UNIX) do 'ls x*y' and get all the files whos names begin with x and end with y. By the paradigm you just stated, I _should_ have to do 'ls | grep x*y'. The fact is, _even_ the UNIX implementors realized that ls should have a built-in filter on file names. My claim is that any tool which reports information summaries (like ls, ps, who, etc.) should have the built-in capability to filter on any of the categories of information that it reports. Your above statement is perhaps the single thing I object to most in "UNIX think". This seems to be a discussion of analogy, so I'll give another. Let's agree to a definition: a "commuter car" is just simple, basic transportation with good mileage, etc. - no extras. Now, what _I_ want from a computing environment is a collection of tools analogous to commuter cars (at least - I'll accept a tool that does more, but not one that does less). What "UNIX think" wants to give me is a set of components with which I must reconstruct a car every time I drive. > [...] You want *everything* built > in (at least everything that you would use) to every program. No, that's not exactly what I want. To keep to the car analogy, I don't ask for all cars to be limos with the TV, phone and bar, etc.. What I _do_ ask is that each be equipped for all aspects of its basic functionality. I don't want to get into the car and end up with "Oh damn. I forgot to install the engine this morning." Ok, so you say "build a script to put the engine in". Fine, except scripts are inefficient and the engine _really_ should have been there to begin with. So should things intimately connected with the transport function - even if not really _required_ for it (like headlights, windshield wipers, and rearview mirrors). > [...] > PS Why use grep for the 'ls -before 1/1/91' command. [...] Well actually, I was arguing _against_ the use of grep for this. grep happened to be the specific example of a general class of tools that I was speaking against. There is no other filtering tool that takes a list of lines, each containing a date field, and passes only those whose date field preceeds a specific date. > [...] There > are better ways. Try 'find'. (You may want to grep the output.) Well, 'find' _does_ have filters built-in for similar time related filtering (against the advice you have been offering for UNIX tools). I'm happy to see that you regard this as a better way. However, the 'find' filters only list files that have been accessed or modified (each a separate filter) _since_ 'n' days ago. There is no way of telling it to list the files that were last modified _before_ a given date. And, indeed, that's the other problem with 'find': I usually don't know how many days it's been since a given date (my example was 1/1/90 and not this year), at least, not off the top of my head. J. Giles Note: the paradigm of small tools and piping was an early attempt at increasing reusability of software. Recent (well, actually not so recent) development of Object Oriented Programming was directed at this same issue. Now, I have serious reservations about the appropriateness of OOP for programming production codes. But, I think an OOP command shell would solve the reuse problem in the interactive environment _much_ more efficiently and flexibly than tools and pipes do.