Eric Blake <[EMAIL PROTECTED]> writes: > According to Simon Josefsson on 6/27/2005 3:55 PM: >> >> -w is for encoding, -i for decoding. So they are orthogonal. I >> thought about making -w affect decoding to, so decoding would ignore >> (only) newlines after COLS. Could be fixed later on. > > I would have suggested this as well; I like the thought of -w during > encoding adds newline at COL and at EOF, and -w during decoding ignores > newline only at COL and EOF.
Yes. > As to your questions on other command line interfaces, I think base64 > should at least behave as a filter: > base64 < file > file.b64 > base64 -d < file.b64 > file Yup. This is possible now. > As for whether choosing on "base64 abc" whether abc is the filename > containing text to be encoded, or the actual text to be encoded, I would > lean towards filenames. Me too. The tool started out as a debugging tool for me, but it is not the typical use. And 'base64 -s foo' is simple for short tests. Or should it be 'base64 -e foo'? To match 'grep -e ...' or 'perl -e ...'. 'foo' is a string here, not a filename. > Consider that your typical input is arbitrary > length binary data, and passing that binary data directly as a command > line argument is not a typical usage of a textual command line interface. > Besides, if you can easily type the input as an ASCII argument, why do > you need the 133% size penalty of encoding it? For a single file, it > might make sense to support a -o/--output option to specify the name of > the output file. Then "base64" would be equivalent to "base64 - -o -". > I'm not sure of the best approach for scaling it to multiple input or > output files, or if that is even necessary. Dealing with multiple input files could also be done later on, I think it is more important to make sure the arguments are filenames and not strings now. > Does the RFC permit, recommend, or discourage \r\n line endings in base64 > encodings? Since the output is printable, you may want to consider > carefully the decision between opening the coded file in text vs. binary > modes on platforms where they are different. The decoded file must > definitely be opened binary. The RFC is fuzzy on the issue, but I want to discourage too lax treatment of encoded data. Lax treatment create opportunities for side channel attacks, and make implementations complex since they have to deal with various ill-formed input. So without --wrap, I definitely think the file should be opened as binary. But with wrap it is less clear. The RFC doesn't discuss what "newline" means. So I think we should open it as text. More thoughts appreciated. Cheers, Simon _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
