[Toybox] I hate the GNU design aesthetic.

[enh]

On Tue, Sep 27, 2022 at 11:32 PM Rob Landley <rob at landley.net> 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
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220928/fb8e7121/attachment.htm>