hello,
> 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
this is ok as you can easily check if if the caracter won't show. this
is a "good enough" principle: don't try to fix *all* the cases, just fix
yours.
> 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.
I'm really happy that sed, awk and all those commands didn't grown to
the point they are as heavy as dynamic langages interpreters but if you
want do get the job done, perl (and raku if you install it) are there
to cover you:
:w !perl -0 -nE'say 0+(@a=/abc/g)'
:w !raku -e 'say +words.grep(/abc/)'
if you need exactly the word abc:
:w !raku -e 'say +words.grep(<abc>)'
> Observed oddities:
wow ... if you go down that path, you're not finished. Unix has a very
long and complex history of experiments, backward compatibilities,
standards and habits. long time ago i had a project to make shell
programming easier by patching all the tools so they have the same
defaut behavior (for example \t as default separator):
* this is a lot of work
* i didn't bet on a large adoption
so unix sucks as all old technologies.
* if you want something conceptualy less broken, give plan9 a try
* if you want something more polished, give vim+coreutils a try
* if you want something convivialist, obenbsd is the best trade off i
seen (you can also give try to sbase or 9base)
* if you want something more consistent, let's start our project :)
* if you want something perfect, let it go :)
> 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?
life is made of trades off :) sorry.
regards,
marc
