Path: utzoo!utgpu!watserv1!watmath!att!att!emory!samsung!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.questions
Subject: Re: edit first line of long file
Summary: ``Huh?''
Message-ID: <10201:Oct2404:23:3890@kramden.acf.nyu.edu>
Date: 24 Oct 90 04:23:38 GMT
References: <568@inews.intel.com> <4597:Oct2321:44:2190@kramden.acf.nyu.edu> <590@inews.intel.com>
Organization: IR
Lines: 61

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