> >        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.
> 
> (1) If there is a relevant standard (RFC, most likely) that specifies
>     the uuencode format, then our uuencode should conform to it, and

Sorry, no RFC exists.  I looked into this several years ago when we were 
working on the MIME standards.  The BDS man page is the closest thing I found 
to a specification.

If someone wants to revise this man page, it might be worth noting that:

a) uuencode has fallen into disfavor in some circles, notably the IETF
mail standards community, because it doesn't survive some kinds of
character-set translation which are fairly common.  (ebcdic<->ascii
only works if the tables are invertable, and iso8859-1<->iso-636-xx
almost never works)

b) there are at several different variants of uuencode, some of which attempt 
to get around the translation problem, others which provide some soft of 
integrity-check by adding additional characters at the end of a line.  
Needless to say, these variants don't always interoperate with one another.
(Ned Freed <ned@innosoft.com> could give more details)

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

The use of ` is more tolerant of mail transports that delete trailing spaces  
(which was common with Internet<->BITNET gateways, less common these days).   
I seem to remember that the later BSD uudecodes would space-pad a line on 
receipt to work around this kind of transmission error, but that the earlier 
ones would not do this.  Both ` and space work with the obvious subtract 0x20 
and mask with 0x3f code, so going to ` was compatible with the BSD uudecode, 
...but it doesn't work with all of the uudecodes that are out there today.

I'm not sure that either one is more "correct".  Some uudecodes accept only 
space, but some uudecodes can't deal with spaces if any of those trailing 
spaces are deleted.

> 
> It's worth noting that:
> 
> (1) the ULTIRIX and the NetBSD uuencode format manual pages currently
>     _agree_ that it should be a space, and,
> 
> (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.)
> 
> 
> Looking at the SCCS logs on vangogh, i see that the change was brought
> in back in 1985 (!!), and was part of "bug fixes and changes from Rick
> Adams."  Sounds like the format was changed, the docs weren't updated,
> and the old format is still decoded because some systems still use it.


Keith