Path: utzoo!attcan!uunet!wuarchive!usc!samsung!noose.ecn.purdue.edu!ecn.purdue.edu!cyliax From: cyliax@ecn.purdue.edu (Ingo Cyliax) Newsgroups: comp.arch Subject: Re: UNIX mind-set (was: How wrong is MS-DOS?) Message-ID: <1991Jan14.075350@ecn.purdue.edu> Date: 14 Jan 91 12:53:50 GMT References: <11267@lanl.gov> Sender: news@noose.ecn.purdue.edu (USENET news) Reply-To: cyliax@ecn.purdue.edu (Ingo Cyliax) Organization: Purdue University Engineering Computer Network Lines: 79 In article <11267@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: |> |> 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). Grep will also tell you what line it found the pattern on, it's trivial to combine grep with sed/wak in a shell script or alias and have it start up an editor on the file and line that it found the pattern on. |> |> 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. You could use find for this. find . -user jblow -print will do this. |> |> 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. I would use find for this as well. |> |> 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. Well, ls is a program that give you informattion about a file or directory. Find will search the filesystem for files that match certain criteria. Grep searches for regular expressions in the file contents. These are all tools that do a specific task. Combine them and you can do almost anything you want to. That is the power of Unix. |> |> 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.). That's just the point of Unix. Once you have mastered the use of grep, awk and the other text manipulation tools (there aren't that many, BTW), you can use them with commands like who or whatever to do the specific filtering you want. Well, you should pick up some good books on Unix Shell programming and Using Unix. I bet you have a whole shelf full of DOS books as well as books on all the tools you use under DOS (Word, Lotus 1-2-3 etc.), so why not invest in some books about Unix...? |> J. Giles -ingo