HOME | GIT Overview | Script-Archive: (docs) : (wiki) : (git) | ...
Note that while some stuff might cope with just POSIX, I usually silently assume a proper Unix environment including perl, bash and optionally ksh (ATT ksh aka ksh93, not PD-KSH), with a sane LOCALE setting. Most of the shell scripts are bash, but should work with ksh as well as long as they don't depend on arrays or more interesting forms of command substitution.
Some (perl) scripts might still make the assumption that /bin/sh supports set -o pipefail, which e.g. for recent debian/ubuntu may no longer hold, as those system might use dash instead of ksh or bash.
Do drop me a line if you run in such a /bin/sh or bash vs ksh93 problem, esp. if it concerns one of the non-trivial scripts. Also in case you wish to run the scripts on the BSDs, Solaris, or AIX (or HPUX) and run into problems.
Most scrips should be usable with little effort, but I tend to only test and use scripts on the scripts' immediate target platform, which for my personal desktop and LAN setup is 90% Ubuntu/Centos. Note that I will need a bit of extra help from your side in case of HP-UX, as I stopped keeping my setup current around the initial 11i version.
However please don't mail in case of tcsh/csh/PD-KSH-related stuff or things like making nico_cd cope with dash. If you're using the BSDs, the pd-ksh vs. ksh93 issue is a bit more critical there than on other Unix systems.
On the Locale issue: read up on LC_COLLATE when you're using some of the posixish-correctly-broken UTF-8 locales, which make a mess of shell globs like [A-Z]* to suddenly match also files like cannotbematchwithuppercase.
Help for non-trivial scripts is usally available with --help (very old scripts still use -h/-help). The longer scripts may also offer additional help sections like --example(s). All scripts begin with a comment block detailing notes, restrictions and bugs.
Man pages: Currently there are none.
To keep scripts self-contained, I usally avoid separate files like man pages which need to be strictly synchronized which each other. So for the major scripts like emv/sfre, in the future, I may choose to reformat a subset of --help into a man page for a generic command overview. The pod route might also work, but at the moment, it's just not my itch (yet).
For testing one of the scripts with dependencies, it should be sufficient to place any required commands in the same directory as the script itself and add that directory to the $PATH. This also works for configuration files and my perl modules.
I'm a bit of a believer of self-contained scripts, so I'm slightly dissatisfied with the Install-Kitchensink-Approach to finally run a tool that uses the kitchensink but itself degenerated into mere argument handling. Still, you sometimes have a bit of non-trivial reusable code that doesn't seem right for reuse-at-external-tool-level (e.g. Grep.pm/Grep.xchange, or lock.pl and Flock.pm). Generalizing the creation of a perl function for booleans expressions might become a candidate, but abstracting the differing uses and argument handling styles (string vs regex vs synonym-expanding vs index-for-filename into array) would make it very hard to avoid veritable kitchensink-style bloat while also littering a previously readable one-page function with a mess of callbacks and closures.
In the old days, that meant a 'do "$0.FILE";' to allow placing the library file into the same dir as the tool (my early 90's perl4/perl5 db_cgi.pl grab bag comes to mind). A no-hassles approach I still like for configuration files.
Nowadays I'm keeping the module collection in a subdir below the tools, but I've some code in any module-using perl script to retain a bit of flexibility in the placement of the modules: <same-directory>, ~/bin, ~/bin/perl, ~/bin/perl/Compact, with the module now being invoked by it's relative name: 'use Flock;' instead of the proper 'use Compact_pm::Flock' which requires a placing Flock.pm in a Compact_pm dir in some directory in @INC).
To download a file, go the directory of interest using the filelist or the git view of the repository, select the file you're interested in and choose the 'raw link' to download. You can also clone the whole archive with git clone git://github.com/jakobi/script-archive.git or grab a current tar-ball (about 500K tar.gz).
HOME | GIT Overview | Script-Archive: (docs) : (wiki) : (git) | ...
jakobi(at)acm.org, 2009-07 - 2012-03