edit first line of long file

[Blair P. Houghton]

In article <10201:Oct2404:23:3890 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <590 at inews.intel.com> bhoughto at cmdnfs.intel.com (Blair P. Houghton) writes:
>> In article <4597:Oct2321:44:2190 at kramden.acf.nyu.edu> brnstnd at 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."