[Toybox] [PATCH 2/2] macOS: use -E rather than -r for sed extended regular expressions.

[Rob Landley]

GNU sed supports -E, -r, and --regexp-extended. BSD sed only supports
-r.
---
scripts/genconfig.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/genconfig.sh b/scripts/genconfig.sh
index 533df60..3887b07 100755
--- a/scripts/genconfig.sh
+++ b/scripts/genconfig.sh
@@ -144,7 +144,7 @@ genconfig > generated/Config.in || rm generated/Config.in
toys()
{
- sed -rn 's/([^:]*):.*(OLD|NEW)TOY\( *([a-zA-Z][^,]*) *,.*/\1:\3/p'
+ sed -En 's/([^:]*):.*(OLD|NEW)TOY\( *([a-zA-Z][^,]*) *,.*/\1:\3/p'
}

Applied, but this raises the question of whether $SED in make.sh is still
needed? (I applied a patch from a macos dev who said it worked, I had a mac but
my apple store subscription was so screwed up an hour from a mac expert who knew
where the secret hidden error logs were couldn't get it unborked. I break
everything. Anyway, there patch used "gsed" instead of "sed", which is gnu sed.
The above wasn't using that because I forgot. :)

If we don't need gsed, then $SED should probably be removed...

Rob

[Rob Landley]

Post by Rob Landley
Applied, but this raises the question of whether $SED in make.sh is still
needed? (I applied a patch from a macos dev who said it worked, I had a mac but

(i don't --- i'm just borrowing one to see how realistic getting a mac
toybox binary is. the answer seems to be that it's not _too_ bad,
though there are linuxy tentacles even in things like cp and tail. but
for my money, just having all our builds use the exact same sed would
still be a win.)

I can probably do a dependency-free-ish scripts/sed.sh without _too_ much pain.

Post by Rob Landley
my apple store subscription was so screwed up an hour from a mac expert who knew
where the secret hidden error logs were couldn't get it unborked. I break
everything. Anyway, there patch used "gsed" instead of "sed", which is gnu sed.
The above wasn't using that because I forgot. :)
If we don't need gsed, then $SED should probably be removed...

see my other mail. if you agree to the suggestion of an error, i'll
send you another patch that adds an error if you're on a mac and not
using gsed, and switches this to $SED.

Sounds good to me, but lemme take an evening to try to whip up a standalone
scripts/sed.sh build first...

Hmmm. Ugly first pass, but with the attached and:

cc -funsigned-char -I gsed -I . -Os -fno-strict-aliasing \
-DTOYBOX_VERSION=\"no\" lib/*.c main.c toys/*/sed.c

I got what seems to be a functioning sed binary?

(I could generate most of that _with_ a sed invocation against generated/ so it
stays up to date each release, and really all the contents could be in one file
and the rest could just be "touch blah.h blah.h blah.h blah.h...")

The question is, does it build/run on macos? If so, I could add a compile-time
probe to build toybox sed if the host sed can't jump to a forward label and
stick it in the $PATH...)

Post by Rob Landley
Rob

Rob

[Rob Landley]

Post by Rob Landley
The question is, does it build/run on macos? If so, I could add a compile-time
probe to build toybox sed if the host sed can't jump to a forward label and
stick it in the $PATH...)

it builds, but if i try to build toybox with `export
SED=~/toybox-gsed` i get bad generated files. flags.h, for example,
only has the generic toybox stuff and is missing all the toys.
likewise newtoys.h. (there are no error messages though.)

Huh. Ok, _that_ is a bug and I should track down what's going on there. (Lemme
see if I can reproduce it on Linux, or if it's a macos thing. Actually, if you
built sed normally with gsed on the host, does the resulting toybox sed behave
properly? That's the "did I screw up the config" or "is the libc regex behaving
differently".)

(If the macos libc regex() is behaving differently, I'm not sure I can fix that.
Might be able to work around it with a preprocessing wrapper though?)

oddly, `make test_sed` on macOS passes all the tests. (well, once i
replace all the `sed` invocations in scripts/ with `gsed` so i can
actually build the single tool.)

Needs more tests then.

the good news, actually, is that for the toys i've been able to build,
most of the tests pass. the exceptions are where the test relies on a
decent sed/realpath/whatever, which isn't going to be true on the mac
(we actually use python for that kind of thing in the NDK!), plus
xargs' "too long" cases, which appear to be legitimately different on
macOS.

The xargs too long cases are a moving target on Linux. I roped you into that
conversation a few months back. :)

Still Rob