Ahh, thanks for that. I tried [pre]...[/pre] but that didn't work. I'll have to try and remember those.

BTW, even in code tags it didn't work:
(should be on separate lines.)

Weird! Perhaps the parser is trying to interpret the "[*]" as part of a nonexistent list construct. If you double-space that input, it displays as single-spaced lines.

BTW, watch out for the 'N' option in sed. If it hits an end of file it'll terminate the script prematurely. Here I've added an extra line of input 'seven'.

As you can see, the script terminates prematurely before doing the s/// on the final line when it tries to append(N) the non-existent line 8.

1 members found this post helpful.

Really nice explanation. This makes it perfectly clear. I wasn't confused by * actually, I simply didn't understand how sed interpreted it and the 'trick' (which now seems perfectly logical) with the \n line. Now it's clear that the \n remains there where it should be (as it's not matched). I kept thinking there was a \n at the beginning of the first, third, etc. lines (because that's where it matched the string, but concomitantly I knew that \n* could match no \n at all, as rknichols had already explained) - which didn't make sense, yes I think I'm really starting to finally understand N. Thank you!

So basically the newline isn't matched (as there's no additional line) and that's why there's nothing to substitute and it ignored the last line, if my understanding is correct.

P.S. By the way, I used square brackets within codes by pressing an addition 'enter' where I knew the line would split and it works like that, even if it's not so practical with a long quoted text.

on the last line N could not be executed. As you stated before already \n* matches anyway (including the empty string), so the real reason is: sed stopped at the command N (because it failed) and did not try to substitute any more.