Why Ian uses so many Shell Scripts

It has often been remarked that most of the file manipulation utilities I write are, at best, difficult to work with. For instance, they tend to write to the screen instead of a real file, even when they're clearly not going to be used as filters. Why is this?

Simple really. You're not expected to work with them. Even I'm not expected to work with them.

Why? Because I prefer to keep the basic "functionality" of the program separate from any "policy decisions" affecting its use. Consider the following:

• If a file is about to be modified, should I rename the original to ".BAK" or just lose it?
• If, on Unix, a file has multiple links, how should this be handled?
• If it turns out that the "after" file is, in fact, identical to the "before" file, should the timestamps be updated, or reset to what they were before?
• Should an attempt be made to preserve access permissions? How about inode number?
• Should the utility have a "~/*.rc" file? If so, should it be processed before or after command-line arguments?
• Should an environment variable be used to determine the location of the .rc file? Or to provide default arguments?

Questions like these tend not to have simple answers - it largely depends on circumstances.

My approach is to have a small binary that does the basic work of the utility, and call it from some sort of script (ksh, make, Rexx, etc) that understands more of the environment I'm working in that day. And, since scripts are quite easy to modify, other projects (or, indeed, other people) are expected to have their own, slightly different, versions calling the same underlying binary.

(If you read the example scripts I've supplied, you might find they implement some totally undocumented features that I just happened to need the day I wrote them. Feel free to add your own.)