Path: utzoo!attcan!uunet!know!sdd.hp.com!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: <600@inews.intel.com> Date: 24 Oct 90 17:50:54 GMT References: <4597:Oct2321:44:2190@kramden.acf.nyu.edu> <590@inews.intel.com> <10201:Oct2404:23:3890@kramden.acf.nyu.edu> Sender: news@inews.intel.com Followup-To: alt.flame Organization: Intel Corp, Chandler, AZ Lines: 126 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."