sharutils bug

Steve L <[email protected]> Tue, 3 Feb 2026 22:54:13 -0800
Newsgroups gmane.comp.gnu.utils.bugs
Message-ID <CABtnAeTXFrWGs_70WgXbQ+vHBYQ2cjTDSMCWwBrj37Yoy_8oeA@mail.gmail.com>
Hi Benson,

I ran into this man page bug and upon googling have found that other people
have run into and thoroughly diagnosed this issue as well, but apparently
no bug report has been made.

In short, the first paragraph of the man page for uuencode says the
following (upon running "man uuencode"):

       uuencode is used to create an ASCII representation of a file
       that  can  be  sent over channels that may otherwise corrupt
       the data.  Specifically, email cannot handle binary data and
       will  often  even  insert a character when the six character
       sequence "0rom " is seen.

The question that comes to mind is, what the heck is "0rom " and why is
that relevant to e-mail. The answer is that the man page source in
uuencode.1 actually says "\nFrom ". You will notice that the "\n" was not
properly escaped, and so groff interprets \n as you would expect, which is
to say not as the literal characters "\" and "n" but as the escape sequence
"\n" which in groff interpolates an as-yet undefined register value, which
defaults to zero. The last person who ran into the problem got a thorough
explanation on stackexchange, see URL in next paragraph. The solution is
simply to use a double backslash in uuencode.1, which I have verified after
applying the fix by running the command "groff -man -T ascii uuencode.1"

https://retrocomputing.stackexchange.com/questions/30062/why-would-email-transmission-change-the-6-char-sequence-0rom