Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!att!att!ima!ptlcamb!peterb From: peterb@ptlcamb.UUCP Newsgroups: comp.arch Subject: Re: UNIX mind-set (was: How wrong is M Message-ID: <2@ptlcamb> Date: 18 Jan 91 20:15:00 GMT References: <11267@lanl.gov> Lines: 100 Nf-ID: #R:<11267@lanl.gov>:63734:<2@ptlcamb>:1936026729:000:5008 Nf-From: ptlcamb.UUCP!peterb Jan 18 15:15:00 1991 >/* Written 5:05 pm Jan 13, 1991 by jlg@lanl.gov in ptlcamb:comp.arch */ >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. No, the filter is not in ls, its in the shell. Try echo x*y some time. This is the beauty of UNIX shells. Every tool has the same filename matching and expansion, and consistent wildcarding. >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. UNIX gives you the capability to build the car and drive it. If you want to reuse that car, then save the commands in a script somewhere. Everybody would think you were an idiot if you rebuilt your engine EVERY morning before you drove to work. >> [...] 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). I don't care for a limo either, but when the problem requires it, I know that I can build one both quickly and cheaply. With UNIX, I have my choice of different Engines, everything from a PeeWee to a Formula One V12. Also, why should I have windshield wipers if all I need it for is to lug dirt around the yard? >> [...] >> 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. I don't see this tool distrubuted in any other OS either. But I can write one in about 40 lines of script and subfilters. I'm sure you could too. Don't complain that your 'commuter' car only comes in black, Ok? >> [...] 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. In SysV, there is a simple way: touch -m "date" /tmp/foo find . \! -newer /tmp/foo -print rm /tmp/foo The ! construct reverses the sense of the test. -newer compares the data of the file and reports if the selected file is newer (by one second or more) than the reference file. Also, the seperate filters are built into find, not seperate subprocesses. Read the man pages some more, then flame about whats not there. >J. Giles -- Peter Barada / ...!{harvard|bu.edu|think|uunet}!ima!ptlcamb!peterb Phoenix Technologies Ltd. / Peripherals Group / 617-551-5000 (USA) Clone the Bone!!! / Opinions are mine; Phoenix cloned them from me...