Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!olivea!orc!inews!cmdnfs!bhoughto
From: bhoughto@cmdnfs.intel.com (Blair P. Houghton)
Newsgroups: comp.unix.questions
Subject: Re: edit first line of long file
Message-ID: <590@inews.intel.com>
Date: 24 Oct 90 01:38:46 GMT
References: <27338@shamash.cdc.com> <568@inews.intel.com> <4597:Oct2321:44:2190@kramden.acf.nyu.edu>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 57

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."