Re: bug on shar (GNU sharutils) 4.15.2

On 11/26/21 2:01 PM, Paulo Ney de Souza wrote:
> the same command produces a shar file that contains the text. But when we
> execute sh it fails the MD5 check upon extraction:
>
> $ sh file.shar
> x - created lock directory _sh06764.
> x - extracting test.tex (text)
> test.tex: MD5 check failed
> x - removed lock directory _sh06764.
>
> and it produces a file that is recognized as ISO-8859 text and it has all
> accents messed up, as in:...
>
> I know the manual says that the you may have problems e-mailing files
> produced with the -T flag, but this goes beyond mailing -- the file itself
> is corrupted.

Quoting the man page:

     If you have files with non-ascii bytes or text that some mail handling
     programs do not like, you may find difficulties.  However, if you are
     using FTP or SSH/SCP, the non-conforming text files should be okay.

"Don't do that." Perhaps I should augment that caveat with the fact that 
the shell program may also play around with the input characters.

FYI, the "-T" flag says to open the file in "binary mode":

>
>   if (! uuencode_file)
>     {
>       *file_type_p = _("text");
>       *file_type_remote_p = SM_type_text;
>
>       infp = fopen (local_name, "r" FOPEN_BINARY);
>       if (infp == NULL)
>         fserr (SHAR_EXIT_FAILED, "fopen", local_name);
>       *pipe_p = 0;
>     }

The file data are then read and written directly into the output shell 
script -- since no encoding is done. The shell script is written thus:

>   while (fgets (inbf, BUFSIZ, input))
>     {
>       /* Output a line and test the length.  */
>
>       if (!HAVE_OPT(FORCE_PREFIX)
>           && // various sanity checks are all okay
>           )
>         fputs (inbf, output);
>       else
>         {
>           fprintf (output, "%c%s", line_prefix, inbf);
>           (*size_left)--;
>         }