Re: base64 tool?

[Simon Josefsson]

Eric Blake <address@hidden> writes:

> s/provide/provides/
> s/transform/transforms/
> s/expand/expands/

Fixed, thanks!  I really need a flygrammar.el.  Or some english
classes.

>> address@hidden address@hidden
>> address@hidden address@hidden
>> address@hidden -w
>> address@hidden --wrap
>> address@hidden wrap data
>> address@hidden column to wrap data after
>> +During encoding, wrap lines after @var{COLS} characters.  This must be
>> +a positive number.
>> +
>> +If this option is not given at all, no line wrapping will be
>> +performed.  If @var{COLS} is omitted, the default is 76.
>
> Do we really want optional arguments to short options?  POSIX tends to
> prefer required arguments, so that -w76 and -w 76 behave the same.  And if
> base64 is ever adopted by a future version of POSIX, we might as well be
> ready for it.
>
> Also, I wonder if a default of 76 when --wrap is not specified or
> specified without argument, and --wrap=0 as the special case to disable
> wrapping, is more likely to be useful, since printable data usually
> implies useful line wraps.

All good ideas, I think.  I'll change it so -w/--wrap always take an
argument, and 76 is the default, and 0 disable wrapping.

> Is -i valid during encoding, or does your synopsis need to be updated to
> show that -i can only accompany -d?

The latter.

More thoughts on the command line interface:

I think there should be a -s/--string argument that is used when you
want to encode/decode a specific string, i.e. instead of:

base64 foo
base64 --decode foo

you type

base64 -s foo
base64 --decode --string foo

This would allow the following:

base64 myfile.txt

to read a file given as an argument.

However, where should the output go?

'base64 myfile.txt' could create output in myfile.txt.b64.  Then
base64 will work similar to gzip.  'base64 -c myfile.txt' could be
added to print to stdout.  And possibly 'base64 myfile.txt myfile.b64'
could be supported, to specify INFILE and OUTFILE.  Or 'base64
myfile.txt anotherfile.txt' could produce myfile.txt.b64 and
anotherfile.txt.b64.

Alternatively, 'base64 myfile.txt' could produce output on standard
output.  Then you could possibly support 'base64 myfile1.txt
myfile2.txt myfile3.txt' which would concatenate the input and base64
encode it all.  I don't think this mode is very useful.  You can't
decode the data into separate files again.  And if this mode is ever
useful, it is easy to work around by 'cat myfile1.txt myfile2.txt
myfile3.txt|base64'.

More thoughts on the command line syntax are appreciated.

Thanks,
Simon