19

It has always bugged me that sed, which is mostly compatible with ed, doesn't have the same j command (to join two lines together) that ed does. Once upon a time I imagined this was because sed works exclusively on one line at a time, such that its internal architecture wouldn't be able to cope with a previous and a next line at once. But of course sed does have its mysterious g and h commands, manipulating the equally mysterious "hold space". When I discovered that, I remember imagining that it would surely be possible to use the "hold space" to achieve the more or less the same result as a j — except it's not, or if it is, it's intricate and difficult.

I asked about this on Stack Overflow one time, and didn't learn much, although I did get a nice Stack Overflowey lecture on why I shouldn't want a j command in sed in the first place.

So I ask here. Does anyone have any idea why sed has never had a j command? Was it too hard to implement at first? Were the g and h commands easier? Is there some reason why a hypothetical j command was a spectacularly bad idea, or truly impossible to implement?

Me, I can't imagine it would be that hard to implement (certainly no harder than the existing g and h), and I'm still sorely tempted to take a stab at it myself, despite the discouragement I received, except I can't believe no one else has done it already, making me suspect that maybe there is some really good reason not to.

Improve this question
6
  • 8
    I don't know the answer, but I can't think of how many times I've thought, "I'm going to solve this problem by writing a script for awk or sed," and then I ended up doing it with a throwaway C program instead. Then, one day, I discovered Python, and I've never thought to use any other language for filtering text files since.
    – Solomon Slow
    Commented Jul 11 at 12:59
  • 5
    Perl :-p Sometimes I use sed on the command line for substitutions, but that's all. And if you think you need awk, you better use Perl.
    – chthon
    Commented Jul 11 at 13:47
  • Same here, with Tcl.
    – Janka
    Commented Jul 11 at 20:22
  • 2
    +1 for 'nice Stack Overflowey lecture.' :)
    – A rural reader
    Commented Jul 11 at 21:59
  • 2
    N;s/\n// is the equivalent of j in ed. Or you can do extra work with the hold space, but it is not necessary.
    – Chris Dodd
    Commented Jul 12 at 0:50

2 Answers 2

Reset to default
5

I believe that would be the N command. It did join lines, but it left the newline separator. You could then manipulate the pair of lines.

Try:

seq 1 20 | sed -e 'N;s/\n/ /g'

(I think the use of \n in the pattern is a newer extension.)

Improve this answer
4

The nifty thing about the original Unix textutils was their discipline. Each one had a well-defined space in which it worked, and lacked extensions beyond that space. This was a boon to people who needed to get things done: once you'd chosen the right tool, it had no extraneous "features" to trip you up. The documentation could be concise, saving time. So, tr covered character by character editing, sed covered line by line editing, awk could handle context, and there were more specialized things like lex.

The idea of breaking down problems into subproblems that can then be individually solved with well-matched, specialized tools has been diluted in modern times. Still, a workbench can support many jobs better than a Swiss Army knife can.

Improve this answer
7
  • 1
    @manassehkatz-Moving2Codidact Stupid fingers ツ
    – John Doty
    Commented Jul 11 at 16:40
  • 4
    Ah — so this explains why sed doesn't have those fancy, non-line-by-line g and h commands. :-)
    – Steve Summit
    Commented Jul 11 at 17:24
  • 4
    I don't buy this explanation without some evidence—do we have any quotes from early Unix developers about intentionally stripping down the sed command language? I see the "Unix tools do one thing well" story all over, but it feels much more like an after-the-fact observation than something the devs were sweating over as they designed sed. Also, I can't imagine ever pulling out awk as an example of "doing one thing well." :D
    – Chris Bouchard
    Commented Jul 11 at 22:35
  • 2
    But AWK certainly has more than a SNOBOL's chance in hell of being a handy pattern-matching language.
    – dave
    Commented Jul 11 at 23:15
  • 2
    @C Ritchie and Thompson: "Second, there have always been fairly severe size constraints on the system and its software. Given the partially antagonistic desires for reasonable efficiency and expressive power, the size constraint has encouraged not only economy but a certain elegance of design. This may be a thinly disguised version of the "salvation through suffering" philosophy, but in our case it worked." Perhaps not stripping down, but building up within limits. Later, larger programs were possible & simplicity became "an after-the-fact observation."
    – Michael E2
    Commented Jul 12 at 0:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .