RR, R-Repeat Input

Originally a "simple version of cat" from Linux Application Development, rr has been recreated and renamed according to my philosophy of impertinence.

Introduction and general review:

Perhaps first I should explain why, when the original code comprised 695 bytes, my "own" code is only 104 of the same--virtually nothing for a program claiming to do "anything."

Let me begin my arguments by saying that "anything" is a very bad reason to do anything. If excess code is written for the simple reason of writing extra code, in all probability the code is entirely worthless.

The simple example given in LAD (cat.c) lost most of its power as an example (although none of its charm) through the inclusion of the superfluous and seemingly inspired inclusion of <unistd.h>, first of all, and secondly the nutty sort of of "error handlers."

It is my belief that certain errors belong to certain processes, and should not be regarded by others. For example, a reading error has to be an issue with anything which reads. However, since writing is the not the responsibility of a single process, and "errors" may be intended (e.g., throwing away output to /dev/null), the report of a writing error should not be given by the process itself, but instead by its environment.

Furthermore, if a program "dies," as they often do, with a message informing the user "write" or another meaningless wordle--while returning to the machine only an ambiguous value of 1--certainly no good has been accomplished by it.

Heuristic decisions and commentary on workings:

Thus, for the reasons above enumerated, I have decided to report the reading error (as given), success (0), but no message for an error upon "write." If rr fails to write, another program following similar guidelines will catch the error within its own duties of operation: no need to double up.

I do believe that the cat.c source was helpful, although it failed in provision of a canonical "cat" codebase--in fact, its name is a misnomer, as it does not "con-cat-enate files"--the original intention, and the reason for its name. For this reason I will include this file also, even though it more than quadruples the necessary information.

(Oh well, it is in public domain. That is enough to correct many wrongs and let many disagreements be overlooked, not to mention encouragement of fondness for an author.)

Another difference is that rr does I/O using a "char" buffer of four kilobytes (4,096 bytes). Many systems still retain the BUFSIZ parameter of 1024, which is really too small. A 4 KB buffer size allows good performance while maintaining reasonable responsiveness and "reality." It is still intended (and proper) for disks and the surrounding computer space to cushion the read/write even further, as time and technology progress.

Naming:

I hope the name rr retains its shortness and sweetness. It's short for "repeat" if you haven't noticed. :-) Duplicate r's remind you that humor *can* in fact be sensible. (Practicality without puns would be no fun.)

Download:

rr.tar.gz (770 bytes)

A simple Makefile is included for "building" with "make"-compatible systems (gcc -O3 rr.c -o rr). Install the program in /usr/local/bin with mode 755 (or equivalent permissions).

Usage is:

rr [< input] [> output]

Performance is phenomenal, as it ought to be. Something like 1 GB per second is "piped" through on my machine. Low end, yes, low speed, no. Maybe I should say it drinks its bytes! :-) Anyway, I wouldn't call it grunting; rather, I would call it a breeze.

Maybe you should drink your bites, too. Sweet and good.

;-)

http://www.myersdaily.org/joseph/unix/rr.txt