Re: uuencode: multi-bytes char in remote file name contains bytes >0x80

[Bruce Korb]

On 07/06/11 10:17, Eric wrote:
> Hi all:
>
>     If there are characters in /decode_pathname/ that are not in the portable
>
>       filename character set the results are unspecified.
>
>
>    I think we could do some work to solve the non-ASCII file name problem
> according to the above feature. the implementation is not a problem, the
> point is whether it is necessary or not to do so ( add an option for uuencode),
> if not, then we would use other tools to solve the problem; otherwise we
> could discuss on how to implement.
>
>    so is it necessary to add an option to uuencode?

I think that, even though not completely necessary, an option should be 
required.
The reason being that there are non-portable characters used in file names
that are nonetheless, 7-bit ascii characters and work as expected now.
By encoding these files, current versions of uudecode become confused.
A common name (e.g. with a '+' character, "clang+llvm.tar.gz", becomes
"hex-encode:636c616e672b6c6c766d2e7461722e677a") and the old uudecode
would create a file with that long name.  The encoding needs to be an option.

A marker is required on the output so that uudecode can detect an encoded
file name.  The encoded file name should be of such a format that old
uudecoders create some sort of file that can get renamed.

========

I think the arguments are sufficient to make the changes.
The change will include uudecode changes so it can detect
and handle the encoded file names, and uudecode will get
an "encode-filename" ("-e") option.

duhuanpeng, I will do this in the coming weeks.
Please be patient.

Thanks.  Regards, Bruce