Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!cs.utexas.edu!ut-emx!ibmchs!auschs!awdprime!doorstop.austin.ibm.com!tif
From: tif@doorstop.austin.ibm.com (Paul Chamberlain)
Newsgroups: comp.unix.questions
Subject: Re: Unnecessarily long pipelines
Message-ID: <2846@awdprime.UUCP>
Date: 23 Jul 90 16:48:25 GMT
References: <price.648165820@chakra> <2358@root44.co.uk> <3043@skye.ed.ac.uk> <836@ehviea.ine.philips.nl>
Sender: news@awdprime.UUCP
Reply-To: tif@doorstop.austin.ibm.com (Paul Chamberlain)
Organization: IBM AWD, Austin, TX
Lines: 24

This should be in comp.unix.gripes

In article <3043@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes:
|In article <2358@root44.co.uk> gwc@root.co.uk (Geoff Clare) writes:
|>Why is it that people string together lots of "grep" commands ...
|Because they can remember how to do it without thinking of course.  Just
|like most csh users type "mv fred.c fred.c.old" instead of the shorter
|"mv fred.c{,.old}"

I interpret this answer as saying "its easier to type than think" which
is often true.  But, when writing a shell script I would hope that any
reasonably good shell programmer would spend the extra 2 minutes thinking
time to get a script that will run twice as fast.  Especially if the
script in question is one that will run often or during heavy system load.
(I seem to recall this one was trying to kill runaway process forking.)

I have seen a question answered with a shell script which invoked awk once
for each line in a potentially large file.  I spent a few minutes on it and
had a solution that would easily run ten times as fast.  The awk solution
was more obvious than looking up or experimenting with some less familiar
features of the shell.  (details omitted and fading from memory)

Paul Chamberlain | I do NOT represent IBM         tif@doorstop, sc30661@ausvm6
512/838-7008     | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif