Re: Introducing base64(1)
- In reply to: Piotr P. Stefaniak: "Introducing base64(1)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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