Improved Connoisseur's Shar

[Gary Perlman]

> in re: shell archives in net.sources (see Ref's line articles).
> 
> but wait!  here's a 2000+ line c program that runs several times
> slower, does not protect against >From, requires the recipient to edit
> the archive before extracting it, and has a host of other ills.

Grrr!  You mean 200+ not 2000.  It is not several times slower,
and it optionally protects agains >From.  No you do not have to
edit the archive.

You make a good point about simple shell scripts compared to
C versions, but I don't appreciate you misleading message.
Sorry about posting this to net.unix, but I don't take
character assasinations without comment...

I think Allan Funt used to say,
"No matter where you are, sometime, when you least expect it,
someone may step up to you and say, `Hey bud, your program sucks!'"

As much as anyone, I am a fan of tiny shell scripts.
When I look at a C program that replaces a shell script,
I am always uneasy about the ratios of sizes, often 100:1.

C programs are supposed to run faster than shell scripts,
but they don't always.  Many shell scripts simply call C
programs once, and the overhead of this is small.  Often,
the C programs called are optimized for their purposes.
A good example is cat, which will copy its input to output
about as fast as any program.

But shell scripts become limited when you want to do certain
sophisticated processing.   That was the case with shar.
I wanted more functionality, and I did not want to use
the shell as a real programming language.

You can argue that my C program adds functionality that is
not useful to you.  I have found the capability to shar
directories useful, and on occasion, I want to be able to
add a prefix to each line of the file.  I also like to get
better diagnostics; something I tried to put into my C shar.

But, let's see what the real story is on the speed question.
Can I write a C proram that underperforms a shell script?
Guilty, your honor, but with an explanation.  I timed the
posted shell shar against my C version, several times,
on two jobs: a bunch of little files, and a few big files.

    shell             C shar          new C shar
user    system    user    system    user    system
1.29    9.1       0       0.59      0       0.6      13 little files
1       1.84      1.76    0.39      1.78    0.34     2 big files
1.145   5.47      0.88    0.49      0.89    0.47     average
    6.615             1.37              1.36         user + system time

When you look at the little files, my clunky C program does not
look too bad.  When you look at the big files, you get another picture.
C is good at iteration, a task the shell is slow at.  My C shar is
a slow cat program, something cat is better at.  I put in a fix to
my C shar to be better at catting, and this is reflected in the
data for the new C shar.  It looks like I accomplished nothing.
I compared my C shar against cat, and I have no idea of how cat
is so much faster, but I would be happy to build it in to my shar
if someone would tell me how.

In my old shar, I read and wrote the text with fgets and fputs.
Why did I look at every line in the file?
So that I can put in a prefix to protect "From" and "~" lines.
Also, I check to make sure the final line ends in a new line
to add one for incomplete last lines.
Otherwise, the EOF delimiter will not be recognized.

The motivation for writing the shell shar was to provide
a portable way of sending files in the mail.  I think the
shell version works well for most cases, but that the
extra features mine provides makes a C version worthwhile.
>From another position, I can see it as some recreational
programming gone out of control; note the number of options
that have been added.

As usual, I am left with an empty feeling by people who prefer to
provide misleading criticisms instead of being constructive.
I would like to point out that I've gotten many more positive remarks
and even some private bug fixes/enhancements.

And like I always say,
	"Don't look a gift horse in the mouth, but if you do,
	please look carefully."

Gary Perlman/Wang Institute/Tyngsboro, MA/01879/(617) 649-9731