[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug on shar (GNU sharutils) 4.15.2
From: |
Bruce Korb |
Subject: |
Re: bug on shar (GNU sharutils) 4.15.2 |
Date: |
Sat, 27 Nov 2021 13:33:21 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
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)--;
}