Re: bug on shar (GNU sharutils) 4.15.2

[Bruce Korb]

Hi Paulo,

On 11/27/21 6:26 PM, Paulo Ney de Souza wrote:
> ... but above all what is most disturbing is the fact that it acts 
> erratically on similar files.
It shouldn't be erratic (behaving differently on the same inputs).
> It works on some files and the you add a character and it no longer 
> works -- this is crazy!
The shell is having its say as to how characters are being interpreted. 
This program, with the -T option, assumes that the input file is 
ordinary text and, as such, can be read in as plain bytes and written 
out to the shell script. If the shell sees non-ASCII characters and 
misbehaves, there's little this program can do about it.
>     Yeah .. but if you are doing only SCP you should be able to
>     shar/unshar
>     completely fine, and get back the same file you started with. No?
If you're using SCP you should SCP the original file instead of trying 
to roll it up in a shell script, copy the script and then unroll the 
file by running the script. It's a waste of bandwidth and a lot of 
bother. And, as you've noticed, you must *NOT* use the "-T" option if 
you are copying a file that is not pure, plain ASCII text.
>     It clearly states:
>
>     
> .............................................................................However,
>     if you are
>          using FTP or SSH/SCP, the non-conforming text files should be
>     okay.
Sounds like some clarification is in order, but not changes to the 
program itself. Don't use "-T" or, better, don't use shar/unshar at all. :)
>         FYI, the "-T" flag says to open the file in "binary mode":
>
>
>     But -T stands for:
*INTERNALLY* it says to open in binary mode because it is saying that 
the input file is pure ASCII text.
>     I understand! But we should either make the program do what the
>     man page says or vice-versa, no?
Patches would be welcome. :)