ddh@hare.cdc.com (Dan Horsfall) (10/23/90)
I've seen this done somewhere, but can't for the life of me
remember what the trick was, or where I saw it...
I have a long text file. I want to pass the first line through a
short sed script, and ignore(i.e., pass unscathed) the rest of the
file.
Plan A: pass the whole file thru sed, qualifing the search string
as "1s/.../.../"; sed will look at each line of the file.
Plan B: pull off the first line with "line", pass it to sed, and
somehow magically get lines 2-n sent to stdout with cat. I'm sure
I've seen it done, with some combination of redirection, parentheses,
pipes, etc., but can't reproduce it from dim menory.
Anybody want to adopt this as their quiz-of-the-day question?
--
Horse
+ Control Data Corporation
Dan Horsfall +1-612-482-4622 + 4201 Lexington Ave North
Internet ddh@dash.udev.cdc.com + Arden Hills MN 55126 USA bhoughto@cmdnfs.intel.com (Blair P. Houghton) (10/23/90)
In article <27338@shamash.cdc.com> ddh@dash@udev.cdc.com (Dan Horsfall) writes: >Plan A: pass the whole file thru sed, qualifing the search string >as "1s/.../.../"; sed will look at each line of the file. sed is the way. it's not that much slower than cat (0.9 seconds cpu vs. 0.0, but the perceived time was about a second either way and computed to 0:00). Anything else would involve multiple exec's and pipes and several context switches for each character of data, and then you get process and I/O collisions. I'll predict nothing (except perhaps awk or certainly perl or C) would be faster than the sed line, and by posting to the net you've just cost yourself and the world more time, bytes, and money than any of these choices could possibly be worth. --Blair "There are perspectives to consider when the software warns you it's about to spend a lot of net.dough."
subbarao@beam.Princeton.EDU (Kartik Subbarao) (10/24/90)
In article <27338@shamash.cdc.com> ddh@dash@udev.cdc.com (Dan Horsfall) writes: >I've seen this done somewhere, but can't for the life of me >remember what the trick was, or where I saw it... > >I have a long text file. I want to pass the first line through a >short sed script, and ignore(i.e., pass unscathed) the rest of the >file. > >Plan A: pass the whole file thru sed, qualifing the search string >as "1s/.../.../"; sed will look at each line of the file. > >Plan B: pull off the first line with "line", pass it to sed, and >somehow magically get lines 2-n sent to stdout with cat. I'm sure >I've seen it done, with some combination of redirection, parentheses, >pipes, etc., but can't reproduce it from dim menory. Hmm - I see what you mean, but I don't think that it involves lots of ( )'s and the like. You can get every line after the first with tail +2 filename. So I guess you'd might want to head -1 filename | sed whatever, then tail +2 filename >> outputfile. As to the speed of this, I'm not sure how fast it would be. -Kartik (I need a new .signature -- any suggestions?) subbarao@{phoenix or gauguin}.Princeton.EDU -|Internet kartik@silvertone.Princeton.EDU (NeXT mail) -| SUBBARAO@PUCC.BITNET - Bitnet
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/24/90)
In article <568@inews.intel.com> bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: > In article <27338@shamash.cdc.com> ddh@dash@udev.cdc.com (Dan Horsfall) writes: > >Plan A: pass the whole file thru sed, qualifing the search string > >as "1s/.../.../"; sed will look at each line of the file. > sed is the way. No, it's not. Try head -1 | sed 's/.../.../'; cat. > Anything else > would involve multiple exec's and pipes and several context > switches for each character of data, and then you get > process and I/O collisions. Hyperbole. No sane program does several context switches for each character of data, and ``process and I/O collisions'' don't exist. sed does much more processing on each character than cat does. On this machine, sed is more than 12 times slower than cat. > I'll predict nothing (except > perhaps awk or certainly perl or C) would be faster than > the sed line, and by posting to the net you've just cost > yourself and the world more time, bytes, and money than any > of these choices could possibly be worth. Your prediction is wrong, and it's the hope of everyone who participates in technical discussions that information received is worth money spent. ---Dan
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (10/24/90)
In article <4597:Oct2321:44:2190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <568@inews.intel.com> bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: >> In article <27338@shamash.cdc.com> ddh@dash@udev.cdc.com (Dan Horsfall) writes: >> >Plan A: pass the whole file thru sed, qualifing the search string >> >as "1s/.../.../"; sed will look at each line of the file. >> sed is the way. > >No, it's not. Try head -1 | sed 's/.../.../'; cat. How does this prevent the first line from appearing twice on the output, provided you've decided (it doesn't seem you have) how to pipe it to the output or from the input? Solve the problem? >> Anything else >> would involve multiple exec's and pipes and several context >> switches for each character of data, and then you get >> process and I/O collisions. > >Hyperbole. No sane program does several context switches for each No single sane program; he was looking for shell-based solutions. Any pipelined command implies at least two context switches, maybe more, depending on the degree to which nfs is involved. >character of data, and ``process and I/O collisions'' don't exist. sed Process and I/O collisions ALWAYS exist. This is comp.unix.*. If you want comp.realtime or comp.sys.ibm.pc.* you know where to find them. >does much more processing on each character than cat does. On this >machine, sed is more than 12 times slower than cat. Okay. Use perl. >> I'll predict nothing (except >> perhaps awk or certainly perl or C) would be faster than >> the sed line, and by posting to the net you've just cost >> yourself and the world more time, bytes, and money than any >> of these choices could possibly be worth. > >Your prediction is wrong, and it's the hope of everyone who participates >in technical discussions that information received is worth money spent. Usually just beginning the discussion rather than making the decision is a matter of wasting more money than the problem could possibly be worth. The information I imparted is well worth far more than the money I received for it. --Blair "Yours, however, isn't worth the -- aaaaah, yer not worth it."
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (10/24/90)
In article <4597:Oct2321:44:2190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: | > sed is the way. | | No, it's not. Try head -1 | sed 's/.../.../'; cat. Okay, results below. | On this | machine, sed is more than 12 times slower than cat. results: Script started [y.tmp] at Tue Oct 23 23:03:14 1990 $ ls -l x.tmp -rw-r--r-- 1 davidsen users 143405 Oct 23 23:01 x.tmp $ time cat x.tmp > /dev/null real 0m0.50s user 0m0.00s sys 0m0.36s $ time sed '1s/foo/bar/' x.tmp > /dev/null real 0m2.20s user 0m1.42s sys 0m0.40s $ time { head -1; sed 's/foo/bar/'; cat; } < x.tmp > /dev/null real 0m3.16s user 0m1.86s sys 0m0.70s $ exit Script ended [y.tmp] at Tue Oct 23 23:05:28 1990 How 'bout that! The overhead of all the other stuff made it slower. I guess I'll vote for using just plain sed, because it's easier, faster, uses less memory, etc. I didn't create a multi-megabyte file, so there may be a break even point, but I wouldn't bet on it. Other points: Yes, this was ksh, so the time reported is for all processes. /bin/time would not do as well unless you started a subshell. Your 12:1 slower surprised the hell out of me, but you are definitely in the right order of magnitude, perhaps even being a little nice to sed. I really would have expected sed to just bypass the stuff after line 1. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/24/90)
In article <590@inews.intel.com> bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: > In article <4597:Oct2321:44:2190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > No, it's not. Try head -1 | sed 's/.../.../'; cat. > How does this prevent the first line from appearing twice > on the output, Huh? First the head runs, grabbing the first line and putting it through sed with output to wherever. Once sed has finished, cat runs, putting the rest of the file through. This solves the problem posed by the original poster. > provided you've decided (it doesn't seem you > have) how to pipe it to the output or from the input? Huh? You just put parentheses around the command I gave, and use the shell's | or < or > for redirection. > >> Anything else > >> would involve multiple exec's and pipes and several context > >> switches for each character of data, and then you get > >> process and I/O collisions. > >Hyperbole. No sane program does several context switches for each > No single sane program; he was looking for shell-based > solutions. Any pipelined command implies at least two > context switches, Huh? Sure, dozens of context switches, but you said several *per character*. That's hyperbole. On this system, cat does two context switches per 1024 characters. 1024 != 1. > >character of data, and ``process and I/O collisions'' don't exist. sed > Process and I/O collisions ALWAYS exist. This is comp.unix.*. Huh? I don't know what you mean by ``collision'' here---everything is nicely synchronized. What ``collision'' are you pointing to in the command I gave? What two things are colliding? > >does much more processing on each character than cat does. On this > >machine, sed is more than 12 times slower than cat. > Okay. Use perl. Huh? *Nothing* is going to run more quickly than cat, and programs that do any sort of processing are guaranteed to run more slowly. How about timing these things for yourself? > Usually just beginning the discussion rather than making > the decision is a matter of wasting more money than the > problem could possibly be worth. Huh? If you believe this, fine. Drop comp.unix.questions from your system. Someday read Hofstadter's writings on superrationality. > The information I imparted is well worth far more than the > money I received for it. Huh? Not to flame, but I haven't seen a correct technical statement from you in this discussion. You gave an opinion, namely that the poster should do what he's been doing---but you could assume that he would do exactly that without any responses at all. ---Dan
chris@mimsy.umd.edu (Chris Torek) (10/24/90)
In various articles Dan Bernstein and Blair Houghton fight over whether (head -1 | sed "$cmd"; cat) or sed "1$cmd" is better for applying a change to line 1 of a long file (see Subject). Blair shows results for a tiny file in which sed is faster; this is not relevant unless `a few lines' is considered a long file. Dan argues that sed is `more than 12 times slower than cat'. All of this overlooks a more basic problem. Although Dan is right about the efficiency argument on most machines (on some, the I/O is slow enough that the difference between `sed' and `cat' is that `cat' simply spends more time waiting for the disk), I have to side with Blair. Use `sed' and restrict the operation to line one. The problem with `head -1;cat' is that it does not work. On many machines, head uses standard I/O, and stdio reads in a block and head prints out the first line. Then head exits, leaving the file seek pointer pointing at the second block. Cat then reads and prints blocks two through the end. At least one POSIX draft has attempted to mandate that stdio should `reset' the input seek pointer so that (head -1; cat)<foo would produce an exact copy of file foo. (I say `attempted' because the wording I saw was utterly unintelligible. The problem is tricky since an application can fork, and the child had better not reset the parent's seek pointers, unless maybe the file was read further in the child, in which case maybe it ought to reset them but only to where they were, except if the parent was also reading the file, except that the child has no way to tell, but if we throw in words like `active file pointer' we can confuse everyone and keep them from realizing that none of this works at all anyway if the input is a pipe; if we keep the sentence running on long enough all the readers will have given up long before the dead giveaway in the previous clause, so. . . . :-) ) This approach is doomed to failure (see previous parenthetical remark), and in any case there are plenty of systems on which (head -1;cat)<foo produces a copy of file foo with all of block zero, except for the first line, removed. (Actually, the previous is not entirely accurate, if the first line is longer than one block. But in (n-1) out of n cases some of the file is lost.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
pfalstad@shine.Princeton.EDU (Paul John Falstad) (10/24/90)
In article <2164@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >In article <4597:Oct2321:44:2190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >$ time { head -1; sed 's/foo/bar/'; cat; } < x.tmp > /dev/null > >real 0m3.16s >user 0m1.86s >sys 0m0.70s >$ exit >Script ended [y.tmp] at Tue Oct 23 23:05:28 1990 > > How 'bout that! The overhead of all the other stuff made it slower. I >guess I'll vote for using just plain sed, because it's easier, faster, It has the added bonus that it works. I tried the following on my system: % cat >foob foo bar ^D % ( head -1 | sed 's/foo/bar/' ; cat ) <foob bar % However, the following does work: % ( head -1 | sed 's/foo/bar' ; cat ) foo (me) bar foo (me) foo bar (me) bar % The latter works because the tty groups the input by line. The first packet goes to head, and the rest of the packets go to cat. Everything works fine. In the former case, the input is grouped by blocks. Since I have such a small test file, head grabs the whole input, passes the first line to its output, and throws the rest away. If I try this with /usr/dict/words, the first line gets passed through sed, the rest of the first block gets junked, and cat prints the rest of /usr/dict/words, skipping everything before 'annihilate.' So apparently head and cat only work if you type the input at the tty. Not very useful. Oh well. -- This is a delicate, sensitive, well-brought-up game which does not recognize the word... well, Whatever it was you just said that we do not recognize. What would Miss Manners say? Who the fuck do you think you are, anyway? Please use another, nice word instead. [from the game Bureaucracy]
maart@cs.vu.nl (Maarten Litmaath) (10/24/90)
In article <10201:Oct2404:23:3890@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: )... )> > No, it's not. Try head -1 | sed 's/.../.../'; cat. )... )Huh? First the head runs, grabbing the first line and putting it through )sed with output to wherever. Once sed has finished, cat runs, putting )the rest of the file through. This solves the problem posed by the )original poster. Your solution does _not_ work. Try it! Hint: what if `head' were using block-buffered IO? -- Waiting for this to work: cat /internet/cs.vu.nl/finger/maart
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (10/25/90)
In article <10201:Oct2404:23:3890@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <590@inews.intel.com> bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: >> In article <4597:Oct2321:44:2190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >> > No, it's not. Try head -1 | sed 's/.../.../'; cat. >> How does this prevent the first line from appearing twice >> on the output, >Huh? First the head runs, grabbing the first line and putting it through >sed with output to wherever. Once sed has finished, cat runs, putting >the rest of the file through. This solves the problem posed by the >original poster. Not without the following it doesn't: >> provided you've decided (it doesn't seem you >> have) how to pipe it to the output or from the input? > >Huh? You just put parentheses around the command I gave, and use the >shell's | or < or > for redirection. ...finally. >> >Hyperbole. No sane program does several context switches for each >> >> No single sane program; he was looking for shell-based >> solutions. Any pipelined command implies at least two >> context switches, > >Huh? Sure, dozens of context switches, but you said several *per >character*. That's hyperbole. On this system, cat does two context >switches per 1024 characters. 1024 != 1. That depends. It depends on how cat got its characters. If cat is reading from the file it may buffer by blocks; if it's reading from a pipe it'll buffer by lines. (You're right that I'm not going to bother looking for unbuffered situations). >> >character of data, and ``process and I/O collisions'' don't exist. sed >> Process and I/O collisions ALWAYS exist. This is comp.unix.*. > >Huh? I don't know what you mean by ``collision'' here---everything is >nicely synchronized. What ``collision'' are you pointing to in the >command I gave? What two things are colliding? Sorry. Underdescriptive metaphor for process scheduling and priority conflicts and contention for I/O resources. It's not referent to a single process; it involves the real-time slowdown due to allowing the kernel a chance to give another process the CPU. Unix is a multiprocessing system; I/O is especially tough. But then I suppose you have 1024-byte data busses, as well... (Actually, that could be true if you have a Connection Machine...) >> Okay. Use perl. > >Huh? *Nothing* is going to run more quickly than cat, and programs that >do any sort of processing are guaranteed to run more slowly. How about >timing these things for yourself? Bill Davidsen, who understood your command-list implicitly, did. He showed that that little pipe and that little semicolon and that little invocation of a subshell make your script the loser. Asymptotically, cat should come back. Ideally, sed could be redesigned to simply block- transfer when it reaches the end of the possible pattern space. (And you really should try perl. I've done things like this in what I thought was super-tight C code that Larry Wall then did in three lines of perl; the C took 7 seconds in one case and the perl took 3. It might even out-cat cat.) >Huh? If you believe this, fine. Drop comp.unix.questions from your >system. Someday read Hofstadter's writings on superrationality. I still believe it creates lost profit to go digging for optimizations when the current model is sufficient and market entry would be delayed by the research. Competition leads competitors to improve on your model, so your best strategy is to mine the current market and preemptively improve on theirs. Someday read Robert Lund's writings on technological strategy. Or go to Harvard or Boston U. or MIT and take one of his courses. I wasn't telling the guy *not* to post. I was merely pointing out that the gains he expected were offset by the costs of his posting. If he wants merely to be sophistic, then fine. It still does no good to tweak that last clock cycle or memory location out of a utility routine when the rest of the program is yet to be written. The only real value from these discussions is the sidelights, anyway (like where I didn't see that you meant to put that thing inside a subshell, and so probably didn't a lot of other readers...) I also believe that there are people who really don't know _any_ answer to their question and need pointers. comp.unix.* stay. (I also read alt.flame, so you can send your next message there and expect I'll see it, so you won't have to cross-post back here and clutter up this group any more). >> The information I imparted is well worth far more than the >> money I received for it. > >Huh? Not to flame, Hah! Too late. >but I haven't seen a correct technical statement from >you in this discussion. Your perception is not at issue, here. >You gave an opinion, namely that the poster should do what >he's been doing---but you could assume that he would do >exactly that without any responses at all. I gave my assessment that what he was doing was optimal, and encouraged him to continue. Someday read Jack Nicklaus' writings on confidence. --Blair "Nuts. I'll have to settle for the half."
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/25/90)
In article <600@inews.intel.com> bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes:
: (And you really should try perl. I've done things like
: this in what I thought was super-tight C code that Larry
: Wall then did in three lines of perl; the C took 7 seconds
: in one case and the perl took 3. It might even out-cat cat.)
Probably not, but it depends on how smart your stdio is, and how dumb
your cat is. And of course, it depends on how you write your cat
equivalent--the recent addition of direct read and write system calls
to Perl could make it a close runner-up in the catting category, but
then Sun's cat plays tricks with mmap to do even better, I believe.
Of course, you could call syscall(&SYS_mmap, ...) from Perl...
Erk.
Larrydel@thrush.mlb.semi.harris.com (Don Lewis) (10/25/90)
In article <27144@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >On many machines, head uses standard I/O, and stdio reads in a block >and head prints out the first line. Then head exits, leaving the file >seek pointer pointing at the second block. Cat then reads and prints >blocks two through the end. And then there is SunOS. In 4.0.x, `(head -1; cat) <file' prints the first line twice because the mmap that cat does on its input file doesn't take the file offset into account. In 4.1, they fixed this bug and we now get the same broken behavior as most other machines. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/25/90)
In article <27144@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >At least one POSIX draft has attempted to mandate that stdio should >`reset' the input seek pointer so that (head -1; cat)<foo would produce >an exact copy of file foo. Sounds to me like it's time to disband the POSIX working groups, if they can't think any better than that.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/25/90)
In article <27144@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: > At least one POSIX draft has attempted to mandate that stdio should > `reset' the input seek pointer so that (head -1; cat)<foo would produce > an exact copy of file foo. [ explanation of various problems this would introduce ] > This > approach is doomed to failure I agree. However, your comments do not apply to *specific* programs (such as head)---only to the general problems of kludging this sort of seek into stdio. Many cloners find it fashionable to seek to the ``proper'' place before closing fd 0. The version of head I'm using does this, so my tests worked. My first solution is not portable to versions of head that don't do the same, but it is not ``doomed to failure''; BSD 4.4 could easily ``doom'' it to success. ---Dan
cbp@foster.avid.oz.au (Cameron Paine) (10/25/90)
In <27338@shamash.cdc.com> ddh@hare.cdc.com (Dan Horsfall) writes: >Plan B: pull off the first line with "line", pass it to sed, and >somehow magically get lines 2-n sent to stdout with cat. [...] Try something like: (line | sed 's/root/ROOT/'; cat) < /etc/passwd Cameron -- cbp@foster.avid.oz - ACSnet cbp@foster.avid.oz.au - Internet ...!{hplabs,mcvax,nttlab,ukc,uunet}!munnari!foster.avid.oz.au!cbp - UUCP
cbp@foster.avid.oz.au (Cameron Paine) (10/25/90)
In <1990Oct25.154444.12966@foster.avid.oz.au>, I suggested trying something like: > (line | sed 's/root/ROOT/'; cat) < /etc/passwd Then, in <568@inews.intel.com> bhoughto@cmdnfs.intel.com (Blair P. Houghton) countered with: >sed is the way. it's not that much slower than cat (0.9 >seconds cpu vs. 0.0, but the perceived time was about a >second either way and computed to 0:00). [...] and I felt a bit miffed. :-) So, I did a little experiment. The results were interesting. I took a medium-sized file that many of you will recognise: 2129132 Oct 26 01:45 /usr/local/lib/news/ctl/history The top line of which looks something like: <stuff> 649108360~66386160 news.announce.conferences/494 and time(1)ed the following three commands: (line | sed 's/announce/changed/'; cat) < /usr/local/lib/news/ctl/history real 2:11.4 user 0.3 sys 18.9 sed '1s/announce/changed/' < /usr/local/lib/news/ctl/history real 7:22.1 user 1:35.9 sys 30.8 (line | sed 's/announce/changed/'; cat -u) < /usr/local/lib/news/ctl/history real 1:53.8 user 0.2 sys 19.9 If we ignore the third command (which is a minor variation on the first) we find that the first is 3.36 (real) times faster and 320 (user) times more efficient. I'm too lazy to trial it dozens of times on a variety of hosts but I think you'll get the general idea... Cameron -- cbp@foster.avid.oz - ACSnet cbp@foster.avid.oz.au - Internet ...!{hplabs,mcvax,nttlab,ukc,uunet}!munnari!foster.avid.oz.au!cbp - UUCP
boyd@necisa.ho.necisa.oz (Boyd Roberts) (10/26/90)
In article <10201:Oct2404:23:3890@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Huh? *Nothing* is going to run more quickly than cat, and programs that >do any sort of processing are guaranteed to run more slowly. How about >timing these things for yourself? > Don't be stupid. It depends how cat is implemented. I remember being horrified to find that one verison of cat used stdio fread/fwrite. And they were implemented as _two_ nested loops with a getc/putc in the middle. Was that _slow_ or what? Gotta watch out for those `universal affirmitives' :-) Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (10/26/90)
In article <1990Oct25.165820.13706@foster.avid.oz.au> cbp@foster.avid.oz.au (Cameron Paine) writes: >In <1990Oct25.154444.12966@foster.avid.oz.au>, I suggested trying >> (line | sed 's/root/ROOT/'; cat) < /etc/passwd >Then, in <568@inews.intel.com> bhoughto@cmdnfs.intel.com (Blair P. Houghton) >countered with: > >>sed is the way. it's not that much slower than cat (0.9 Countered? I posted on _Monday_ evening, an easy three days before you did. If that's countering, I'd like to announce I'm countering the price of oil next wednesday; it's going to climb like a rocket. I'd completely forgotten line(1). Apparently, I'm not the only one :-|. --Blair "Gotta go see a broker about some short-selling on the commodities floor..."