Re: Introducing base64(1)

From: Piotr P. Stefaniak <pstef_at_freebsd.org>
Date: Sun, 27 Mar 2022 10:35:21 UTC
On 2021-11-22 19:16:45, Piotr P. Stefaniak wrote:
>Hello archers,
>
>I've prepared a short series of changes:
>https://reviews.freebsd.org/D32943 "Conflate uudecode and uuencode"
>https://reviews.freebsd.org/D32944 "b64encode: implement -w to wrap lines"
>https://reviews.freebsd.org/D32945 "Implement base64(1)"

I would like to start applying these, one by one and see what kind of
issues people will find. Hopefully nothing major.

>First, I modularize uuencode and uudecode by wrapping them in
>bin2text2bin.c ("binary to text to binary"). The program will be
>installed as bin2text2bin, uuencode, uudecode, b64encode, and b64decode
>and will be responsible for running the coders according to their
>historical behavior.
>
>Additionally, bin2text2bin will be able to take a parameter designating
>the coder and accept all its options in this form:
>bin2text2bin <coder> [options]
>and the behavior should be the same as if
><coder> [options]
>was invoked.
>This has the advantage that adding coders won't require installing them
>as binaries. I think quoted-printable or yEnc would be nice, but
>currently I have no plans to implement those.

This one is the one that I'm most concerned about since the change is
pretty invasive structure-wise. It's probably missing some cleanup like
make delete-old, but I know nothing about it.

>Second, I implement an option to b64encode that sets the column after
>which lines wrap. Plus, I accidentally optimize the function that
>produces the encoded output.

>Third, I use the existing b64encode and b64decode implementation and the
>newly implemented option to call it as base64, respecting the syntax of
>that program's invocation.

I updated the two changes mentioned above yesterday. Now getopt_long()
is used only once and then the options are passed to new special-purpose
functions. This seems cleaner than using getopt_long() to reconstruct
options for another getopt_long() loop.

I've done some git-rebasing on the way so that's another thing that
might be wrong - but I find that less likely than bugs of other sort.

Piotr