O 04/09/21 ás 14:26, ropers escribiu:
On 04/09/2021, Parodper <parod...@gmail.com> wrote:
To use newlines with sed I use tr and a char I know does not appear
on the text, like '|' or '`'. I just tested :!sed s/abc/abc€/g % |
tr '€' '\n' | grep -c abc and it worked fine.
That's a neat trick -- IFF you can be *sure* that character won't
show up in the text. I also feel it's a workaround, and I don't
really understand *why* substituting/inserting newlines is something
that seemingly cannot be made to work in OpenBSD sed, or whether the
information on the sed(1) man page is really consistent with actual
behaviour.
Observed oddities:
1. ^V[return] generally yielding CR across the board (on BSD, Linux,
etc.) even though the Unix-like end-of-line character is LF, not CR,
2. \n working perfectly fine in some base utilities like tr but not
in others like sed, and
3. the sed(1) documentation being seemingly or potentially
misleading or at odds with observed program behaviour w/r/t
newlines.
Is anyone able to make sense of this? Does anyone know if there's a
reason or rationale behind the BSD sed implementation when it comes
to newlines? Can someone perhaps even say why ^V[return] produces
CR instead of LF or if there's even a way to enter \n in a way sed
will accept?
Thank you, Ian
I think I found something. From POSIX
(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html):
> A line can be split by substituting a <newline> into it. The
> application shall escape the <newline> in the replacement by preceding
> it by a <backslash>.
So I wrote
:!sed s/abc/abc\/g % | grep -c abc
and then went back and pressed <ENTER> after that backslash, i.e.
:!sed s/abc/abc\<ENTER>/g % | grep -c abc
And it gave me a correct number of abc's for my test text.
