-----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
>
> [EMAIL PROTECTED] base64 invocation
> [EMAIL PROTECTED] @command{base64}: Transform data into printable data.
> +
> [EMAIL PROTECTED] base64
> [EMAIL PROTECTED] base64 encoding
> +
> [EMAIL PROTECTED] 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
> [EMAIL PROTECTED]://ftp.rfc-editor.org/in-notes/rfc3548.txt, RFC 3548}.
> +Synopses:
> +
> [EMAIL PROTECTED]
> +base64 [EMAIL PROTECTED]@dots{} [EMAIL PROTECTED]
> +base64 --decode [EMAIL PROTECTED]@dots{} [EMAIL PROTECTED]
> [EMAIL PROTECTED] 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}.
> +
> [EMAIL PROTECTED] @samp
> +
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> [EMAIL PROTECTED] -w
> [EMAIL PROTECTED] --wrap
> [EMAIL PROTECTED] wrap data
> [EMAIL PROTECTED] 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.
> +
> [EMAIL PROTECTED] -d
> [EMAIL PROTECTED] --decode
> [EMAIL PROTECTED] -d
> [EMAIL PROTECTED] --decode
> [EMAIL PROTECTED] Decode base64 data
> [EMAIL PROTECTED] 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.
> +
> [EMAIL PROTECTED] -i
> [EMAIL PROTECTED] --ignore-garbage
> [EMAIL PROTECTED] -i
> [EMAIL PROTECTED] --ignore-garbage
> [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
-----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-----
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
