Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

9
  • It's very fast. But I don't think you need to read and print - you should just let it go to output all its own. The performance gets better if you build the AST toolkit wholly and get all of the ksh builtins compiled in - it's weird to me that sed isn't one of them, actually. But with stuff like while <file do I guess you don't need sed so much... Commented May 10, 2015 at 13:54
  • I am curious though - how did awk perform in your benchmark? And while I'm pretty sure ksh will likely always win this fight, if you're using a GNU sed you're not being very fair to sed - GNU's -unbuffered is a piss-poor approach to POSIXLY ensuring the descriptor's offset is left where the program quit it - there should be no need to slow down the regular operation of the program - buffering is fine - all sed should have to do is lseek the descriptor when finished. For whatever reason GNU reverses that mentality. Commented May 10, 2015 at 14:05
  • @mikeserv; The redirection pattern match is done until the pattern is found, and the line with the found pattern will not be printed if not explicitly done as depicted. (At least that showed my test.) Note that there's no while; the printing is implicitly done as the defined side effect of the <## redirection operator. And only the matching line needs printing. (That way the shell feature implementation is most flexible for support of incl./excl.) An explicit while loop I'd expect to be significant slower (but haven't checked). Commented May 10, 2015 at 14:07
  • 1
    @mikeserv; Ah, okay. BTW, I just tried the head instead of the read; it seems only a little bit slower, but it's terser code: { head -1 <##XYZ ; { read <##"" ;} >file4 ;} <largefile >file3. Commented May 10, 2015 at 14:18
  • 1
    @mikeserv; Good point; it wasn't. But when I activate the builtin (just done and checked the results) it's the same numbers, strangely. (Maybe some function call overhead compared to read?) Commented May 10, 2015 at 14:23