Re: sharutils bug

It has been years since I've fiddled with sharutils.
Right now, I cannot even access the GNU Git sources.
Thank you for running down the issue. I'll apply a fix
as soon as I am able. :)

Thanks again, Bruce

On 2/3/26 22:54, Steve L wrote:
> 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
>