This is a collection of scripts, mostly shell scripts and mostly for the bash shell, written between 1998 and the present. I'm publishing them as open-source; most of
them contain a copyright notice to that effect, and here is a "blanket" version for the ones that don't: These programs can be modified and/or distributed under the
terms of the GPL, except for those naming a different license. See http://www.gnu.org/licenses/gpl.html for the
terms. There is no warranty.
Each script begins with a comment giving a brief description, and PREREQ info on prerequisites, usually followed by USAGE info. A few have been written in a more thorough style, where either USAGE is a string-variable or Usage a procedure (so the command can respond to a --help request), and where cmdline-args are parsed using getopt (more on this below). See scalepix for an example of this sort. Note: a PREREQ will be mentioned for any program that's required but not included in a typical Linux-distro nor in Windows+Cygwin installed as recomended below.
At the end of each script, after a line consisting of "exit" for a bash script, you'll find things like notes on the algorithm, and a CHANGE-LOG which is a chronological log of modifications.
INSTALLING:
Note: Windows-users can run bash scripts after installing Unix-tools for Windows.
The simplest way to install these scripts is to unzip them into a newly created directory, then to add the name of that directory to the front of your PATH variable's value (if not familiar with the PATH variable, see http://en.wikipedia.org/wiki/PATH_(variable) then google for it).
A few of these scripts have names deliberately chosen so as to replace the "standard" program by that name. For these to behave as intended it's essential they be installed into a directory that precedes (in your PATH shell-variable's value) the "standard" one. One is bc, a way to invoke your standard bc with a set of built-in bc-procedures. Another is llexec which is a way to invoke the standard llexec (part of the Lifelines genealogy package) with an enhanced user-interface. The method by which my llexec finds the standard llexec may be of interest even if you have no need for llexec. It illustrates a foolproof way to "find the other PATH-program of the same name".
THE WEBMASTER-TOOLS:
The Webmaster-Tools are the ones listed in webmaster-tools.htm. Most of them will require some customization before being useful for someone else, and some are so highly dependent on features of my own website that it's hard to imagine them being useful to anyone else (these are labelled "ER-specific"). One person who may be able to use them without customization is Will Milne who's taking over as webmaster for Nativeorchid.Org and Debwendon.Org.
Some of them use regular-expressions via grep and sed to select and modify HTML and will only function correctly on HTML written in a simplified subset of HTML. The comments will explain limitations of that sort -- please let me know if I've missed any.
HANDLING CMDLINE-OPTIONS:
Over the years I've experimented with several programming styles for the parsing of cmdline-options; my early scripts used a mixture of traditional one-letter options, GNU-style long-options, and non-GNU (single-dash) long-options, but using the operand-as-separate-word style; some of these (eg: scalepix) have since been converted to use getopt in order to support operands being either immediately following the option (in same "word") or as a separate word. My webclean script is a departure from the style I'd been using in that it uses the operand-in-same-word style; it is wonderfully simple, wonderfully readable, and I rather like it making me wonder why it didn't promptly become my "new" norm?
When using a bash-script one is happiest with one that uses getopt so that operands may be given either way, and in the GNU-Linux norm. However, the use of getopt means giving up some of what makes bash-scripting so attractive: easy and quick development, including easily added cmdline-options. Note that adding a cmdline-option becomes a good deal more work, involves a good deal of duplication, and becomes considerably more error-prone, when using getopt. Obviously I have yet to find the "right" answer, since what I want is elusive: I want easily modified code, but would also like my scripts to handle options with operands in the customary GNU-Linux manner.
For an interesting exercise in bash-programming, write the code to obtain-operand-for-current-option as a bash function (to support both in-same-word and as-separate-word operands). I don't insist that it be done with a bash function; I'd be happy with any method that's reasonably neat, reasonably readable, readily changeable, free from duplication. Please let me know if you find such. In 2010-12, I tried (again) to achieve these objectives when writing bk-restore and rewriting dif; the bash-function getopnd handles operand in same-word or as-separate-word, although its requirements are other-than-straightforward. This method is now satisfactory for a script having only long-options, however its support for short-options falls well short of compatibility with getopt; for one thing a short-option will also require an equal-sign before the operand for in-same-word operand; furthermore this method won't support the combining of several operand-less short-options into one word.
PACKAGING BASH-SCRIPTS:
When writing or modifying a "set" of related routines especially when each is small, I like the "package" approach where one file contains all the little one-liners; for bash-scripts that style is readily available since one can so package a bunch of routines with each routine being a bash-function, and then any script wanting to use that package contains a source commandline. The publication of Perl routines, for example, has gone that way. However, when I'm writing a bash-script that will be using such "packages" then I like it even better if they've been converted to one-routine-per-file form so that each is automatically available for use by routine-name, by virtue of existing within one of my PATH directories. And that's why I'm publishing them in the one-script-per-file form. Although also in a zipfile for ease of installation.
ENHANCED GLOBBING:
Ever since switching to Linux I've missed the d-command I'd written for MS-DOS in the 1980's. It was my Unix-ls-like replacement for the Dos-dir command, and since in Dos each command does its own "globbing" (supporting filename-patterns or filenames containing star or question-mark) it was natural for my d-command to provide better than the usual Dos-style globbing. My significant innovation was the introduction of a globbing metachar that matches path-segments containing one or more slashes. In Dos, the usual separator for path-segments is backslash, however my Unix-like Dos-commands all support either backslash or slash. Incidentally, supporting Unix-style filenames with slash as the separator between path-components was easier than expected as to my surprise the low-level routines provided by MS-DOS already supported such names.
Providing such enhanced globbing in Linux is less trivial, because in Unix it is the shell that provides globbing, so one needs to write an alternate shell in order to experiment with enhanced globbing, and that's not something I've gotten around to doing. I learned that one of alternate Unix-shells, the z-shell, already had the enhancement I sought, however I've not gotten around to trying it. As of bash-v4, bash also offers it provided one enables its globstar option, and this I have started to use. I quite like my own notation, but suspect I'll learn to live the notation bash offers. Both zsh and bash-v4 use /**/ for two-or-more-slashes separated by names, **/ for one-or-more slashes; my (d.exe) notation uses // for one-or-more slashes (separated by names) resulting in patterns that work surprisingly well in a visual sense.
I enjoy hearing from people using any of these programs, and am always happy to answer questions, ereimer@shaw.ca.