<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 31, 2022 at 11:37 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/31/22 16:55, enh wrote:<br>
>     and if i `CONFIG_TOYBOX_NORECURSE=y`, it calls sed and works...<br>
> <br>
> ...though this might be about to come back and bite me. i'm hearing as-yet<br>
> unconfirmed reports that toybox `tar czf` is a lot slower than gnu tar, and --<br>
> given that they're using --transform` while they're assuming it's tar or gzip,<br>
> i'm wondering whether it's actually the fact that we're forking out to sed for<br>
> every file?<br>
> <br>
> i've asked for repro steps or a `perf record` i can look at...<br>
<br>
When I said I had more work to do there, part of what I wanted to do was add a<br>
sed --tar-xform mode with some sort of protocol that would allow a single<br>
persistent sed to get a name and send back a response without exiting. (That<br>
would also allow me to implement the trailing type indicators.)<br>
<br>
Right now exiting lets you know that it's done processing, even if your sed<br>
invocation included a "d" or something and thus produced no output (so you wait<br>
forever if it DOESN'T exit). And even if I use -z mode you can include \0<br>
manually in a substitution and thus force it out of sync. So the persistent mode<br>
would need some sort of "expect X bytes of output" indicator, probably just a<br>
decimal number of bytes ending with a newline, followed by the transformed<br>
payload. And of course the type indicator needs the incoming name to be<br>
annotated with type information as part of the call-and-response protocol...<br>
<br>
It's not perfect, you can always sed ':a;b a' or something if you want to cause<br>
Horrible Goose levels of trouble. (Tempted to add something like the symlink<br>
resolution limit so 1 billion jumps in a single sed pattern evaluation exit with<br>
an error...)<br>
<br>
The downside of doing that is it would require TOYBOX sed. </blockquote><div><br></div><div>meh, _i_ don't care about that :-)</div><div><br></div><div>(and, more seriously, does _anyone_ care about using a mixture of toybox and non-toybox? i'd imagine the only people who'd even notice would be people like me [or these kernel guys] trying to switch over, and the only reason i/they are switching over one tool at a time is because we've been running slightly ahead of you, using stuff that's not finished yet. i guess it would affect the toybox _tests_ but i kind of thing that's a bug already --- given that i support systems where everything's from toybox it's a misfeature that the toybox tests _don't_ test toybox-with-toybox [and i get no value from them testing toybox-with-gnu].)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Right now it should<br>
work with the host sed. I vaguely plan to try to launch "sed --tar-xform -e<br>
$PATTERN" and then fall back to the old one at a time logic not undestanding<br>
suffixes if sed exits with an error, because toybox commands try NOT to require<br>
other toybox commands. But I can't figure out a better way to do this than<br>
copying half the sed plumbing to lib/sed.c and it really wasn't designed to be<br>
broken up...<br>
<br>
Rob<br>
</blockquote></div></div>