On Tue, Sep 27, 2022 at 11:32 PM Rob Landley <[email protected]> wrote:
> I just added sed --tarxform and taught tar --xform to use it, so a single > persistent instance of sed can speak a simple protocol allowing > call-and-response sed invocation across a pipe. (This didn't work before > for > several reasons: a line that produced no output could block tar trying to > read > the result, a sed invocation adding an extra \n or \0 to the output could > get > tar out of sync, sed wouldn't produce output until it read the NEXT line > of data > so it could do $ matching at EOF...) Anyway, wrapped in a protocol, works > now. > > I'm not pushing the commit publicly yet because I'm hopefully about to > CHANGE > said protocol slightly, to add a type indicator because in > https://www.gnu.org/software/tar/manual/tar.html#transform we have this > little > horror show: > > In addition, several transformation scope flags are supported, that > control to > what files transformations apply. These are: > > ‘r’ Apply transformation to regular archive members. > ‘R’ Do not apply transformation to regular archive members. > ‘s’ Apply transformation to symbolic link targets. > ‘S’ Do not apply transformation to symbolic link targets. > ‘h’ Apply transformation to hard link targets. > ‘H’ Do not apply transformation to hard link targets. > > Default is ‘rsh’, which means to apply transformations to both archive > members > and targets of symbolic and hard links. > > Default scope flags can also be changed using ‘flags=’ statement in the > transform expression. The flags set this way remain in force until next > ‘flags=’ statement or end of expression, whichever occurs first. For > example: > > --transform 'flags=S;s|^|/usr/local/|' > > No, "flags=" is not how sed command syntax normally works, thanks for > asking. > > So now I'm starting at this going: > > 1) Is rsh only the default when there are no scope flags? As in if I tell > it > scope s should that switch off r and h? > > 2) Does flags= interact with the block logic? If I do > > --transform '{flags=S;s/potato/blah/;};s/a/b/' > > should the second transform apply to symlink type? > > 3) If how about jumps? If I b to a :label past a flags= statement does that > prevent the flag change from taking effect? (Is this a parse time > attribute or a > runtime attribute?) > remember that GNU tar explicitly doesn't support _sed_ --- it supports something like looks kind of like the sed 's' command. > The sad part is I strongly suspect I'm putting more thought into this than > the > tar developers did, but I kind of need to know the answers to do it RIGHT. > "any similarity to actual sed, living or dead, is entirely coincidental". tbh, i think all the choices were bad here: 1. invent a new format. now you have two problems. 2. reuse sed entirely. now you have the problems you've been dealing with. (plus a lot of curious "what does <thing> even mean?" questions, because sed is too general for this use case. luckily i doubt we'll ever have to answer those questions, because i doubt anything esoteric is likely to be used. despite hyrum's law, i don't really know anyone except you who writes sed more complex than a single s command, and issues with trying to run your sed programs on macOS suggest that nothing beyond a single s command is portable to different sed implementations anyway!) 3. rewrite that one command from sed. now you have duplication, and potential skew between "actual s command" and "fake s command". option 3 is not obviously a bad choice given the issues with the alternatives, but it's a bad fit for anyone trying to do option 2 instead. > Sigh, > > Rob > _______________________________________________ > Toybox mailing list > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
