honey@down.FUN (code 101) (01/10/85)
in re: shell archives in net.sources (see Ref's line articles). this whole circus drives me crazy! shell archives were first popularized in '82 or so, in the form of 6 line scripts, e.g., echo '# To unbundle, sh this file' for i in $*; do echo "cat >$i <<'//GO.SYSIN DD *'" cat $i echo "//GO.SYSIN DD *" done some people added echo on extraction, others added a prefix character to protect against >From, others added basename. this turned a simple 6 line script into a simple 8 line script. 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. punch line: by all appearances, the authors are proud of their work. amazing. -- peter
perlman@wanginst.UUCP (Gary Perlman) (01/13/85)
> 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