Re: base64 tool?

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Simon Josefsson on 6/25/2005 7:32 AM:
> +++ NEWS      25 Jun 2005 13:28:40 -0000
> @@ -167,6 +167,11 @@ GNU coreutils NEWS                      
>    stat -f's default output format has been changed to output this size as 
> well.
>    stat -f recognizes file systems of type XFS and JFS
>  
> +** New programs
> +
> +  base64 is a new tool that provide base64 encoding and decoding
> +  functionality.

s/provide/provides/

> +
>  * Major changes in release 5.3.0 (2005-01-08) [unstable]

> Index: doc/coreutils.texi
> ===================================================================
> @@ -1764,6 +1767,64 @@ address.
>  
>  @exitstatus
>  
> address@hidden base64 invocation
> address@hidden @command{base64}: Transform data into printable data.
> +
> address@hidden base64
> address@hidden base64 encoding
> +
> address@hidden transform data read from standard input, or the
s/transform/transforms/

> +string given as argument, into (or from) base64 encoded form.  The
> +base64 encoded form uses printable @acronym{ASCII} characters to
> +represent binary data, see
> address@hidden://ftp.rfc-editor.org/in-notes/rfc3548.txt, RFC 3548}.
> +Synopses:
> +
> address@hidden
> +base64 address@hidden@dots{} address@hidden
> +base64 --decode address@hidden@dots{} address@hidden
> address@hidden smallexample
> +
> +The base64 encoding expand data to roughly 133% of the original.
s/expand/expands/

> +
> +The program accepts the following options.  Also see @ref{Common options}.
> +
> address@hidden @samp
> +
> 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.

> +
> address@hidden -d
> address@hidden --decode
> address@hidden -d
> address@hidden --decode
> address@hidden Decode base64 data
> address@hidden Base64 decoding
> +Change the mode of operation, from the default of encoding data, to
> +decoding data.  Input is expected to be base64 encoded data, and the
> +output will be the original data.
> +
> address@hidden -i
> address@hidden --ignore-garbage
> address@hidden -i
> address@hidden --ignore-garbage
> address@hidden Ignore garbage in base64 stream
> +During decoding, ignore unrecognized characters (including newline),
> +to permit distorted data to be decoded.

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

I didn't review the code itself, assuming that the bulk of it has already
been reviewed during the gnulib submission process.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCvXGK84KuGfSFAYARAkRhAKCqCx5FSqPC3TMLa77YSiXUHutBCgCfS8GL
d56ULkSHrCvqTe4w+bXA7Y4=
=9wKi
-----END PGP SIGNATURE-----