[SOLVED] Next in sed \n vs \n*

GazL · 03-11-2017, 05:06 PM

Quote:

Originally Posted by rknichols

The magic incantation to prevent that when not using [CODE] ... [/CODE] tags is "[NOPARSE] ... [/NOPARSE]".

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:

Code:

[*]one[*]two[*]three

(should be on separate lines.)

rknichols · 03-11-2017, 05:25 PM

Quote:

Originally Posted by GazL

BTW, even in code tags it didn't work:

Code:

[*]one[*]two[*]three

(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.

Code:

[*]one
[*]two
[*]three

GazL · 03-11-2017, 06:06 PM

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'.

Code:

test@ws1:/tmp$ sed -e 'N;s/\n*/(*)/' /tmp/sed.in 
(*)one
two
(*)three
four
(*)five
six
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.

vincix · 03-12-2017, 01:02 AM

Quote:

Originally Posted by GazL

It now gets to the end of the script and does an implicit print of the buffer. It prints '(*)one\ntwo' to the terminal, which displays as

Code:

(*)one
two

I suspect part of your confusion is stemming from the fact you are confusing the meaning of '*' in a regex, with the meaning of '*' in a shell glob. They are quite different.
I hope that clears it up for you.

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!

vincix · 03-12-2017, 01:54 AM

Quote:

Originally Posted by GazL

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.

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.

pan64 · 03-12-2017, 04:05 AM

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.