Chris G Demetriou writes:
>>        The uuencode(5) manual page says that the encoding of the final
>>        zero length line is an ASCI space.  This is incorrect; a single
>>        character ` is used.

>While this may be true for the NetBSD version of uuencode, it's
>definitely not true for all uuencodes.  For instance, the ULTRIX
>version _does_ use a space.

The SunOS 4.1.3 and Xenix versions too.  That's all I can check right
now.

>(1) If there is a relevant standard (RFC, most likely) that specifies
>    the uuencode format, then our uuencode should conform to it, and

There isn't an RFC.  The documentation is the source code.

>(2) the manual page should document _both_ behaviours, noting which is
>    more correct.  (obviously, both work...)

The manual page (SunOS uses the same wording) is quite explicit that
the first byte in a line should be in the range 040 - 040+63.

However, suspect that uudecode has always stripped all characters (not
only the characters after the length byte) to 6 bits after
substracting 040 so a backtick would be permissible.

>(2) by the manual page, using the formula given for converting values
>    to printable characters, using space is correct.  (Note that space
>    _is_ defined to be a printable character.)

But the man page doesn't give the formula for converting *from*
printable characters.  While decoding you *must* strip the top 2 bits
to get the value.  That's how uudecode has always worked and other
implementations depend on this (e.g. perl's uuencoder always uses
backticks instead of spaces.)

-- 
Christoph Badura	bad@flatlin.ka.sub.org

You don't need to quote my .signature.  Everyone has seen it by now.
Besides, it doesn't add anything to the current thread.