On 07/05/11 08:06, Eric Blake wrote:
I'm not quite sure what you are asking me to do here. Maybe it helps to
read the current POSIX requirements on uuencode output:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uuencode.html
I read that, though I was sure not as carefully as someone regularly in
on the meeting. :) Reading it again:
> The pathname of the file into which the uudecode utility shall place
> the decoded file. ... If there are
> characters in decode_pathname that are not in the portable filename
> character set the results are unspecified.
==>> ^^^^ needs a comma after "set".
leads me to believe that this:
begin 444 hex-encode-EN:414243
can, for example, be validly used to create a file named "ABC"
in the english language domain, with obvious extensions for CN.
The ":" character being non-portable relieves the application from
being required to create a file named "hex-encode-EN:414243".
It is just that a new uudecode might surprise someone trying
to create a file named "hex-encode-DE:BADF". Given that this sharutil
stuff was supposed to be moribund when I took it over a decade ago,
perhaps not a critical incompatibility.....
Cheers - Bruce
