These scripts are simple and should work out of the box on most UNIX systems. They have been tested on recent Linux, FreeBSD, OpenBSD, NetBSD, Dragonfly BSD, Illumos and Haiku systems. They usually don't have dependencies beyond standard system utilities, but some scripts also depend on other scripts in the same package.
To install the scripts run the following commands:
tar zxf package.tar.gz
chmod +x bin/*
The executable files are placed in ~/bin, the manuals in ~/man/man[1-10], and finally some date files may be placed directly in your home directory. You can check the contents of a package before installing it if you want:
tar tzf package.tar.gz
The above mentioned conventions assume that ~/bin is in your executable search PATH, and that ~/man is in your MANPATH. If this is the case (by default it will be on some UNIX systems), running the scripts and reading their manpages is straight forward:
Even if this isn't the case, you can still execute the scripts and read their manpages manually:
You can check your PATH/MANPATH settings simply by printing them out: echo $PATH ; echo $MANPATH. If ~/bin and ~/man isn't in your executable/manual search path, adding these lines to your ~/.bashrc should do the trick:
The last line here is optional, and unneccessary on some UNIX systems. Debian, FreeBSD and Solaris for instance will include ~/man in your manual search path, if ~/bin is included in your PATH.
It wouldn't be UNIX if there weren't weird edge cases...
Scripts that have a re_ suffix, are simple reimplementations of common UNIX programs. Since most UNIX systems already have these utilities, they are given this suffix to avoid confusion with existing programs. If your systems doesn't have this program, you can safely rename the script, and remove this suffix (even if you do have the program in question, reading the reimplementation source code may prove educational). For example, most UNIX systems have a calendar command, but Linux does not. If you are using Linux you can just rename re_calendar to calendar, and you would have a basic version of this classic UNIX tool on your Linux box.
Note: If the UNIX system you are using doesn't have a certain utility, it doesn't necessarily follow that it lacks the desired functionality. For example, BSD systems dont have the GNU utilities shuf and shred, but the BSD commands sort -R and rm -P does much the same (the GNU version of sort and rm on the otherhand dont have this functionality).
The default version of awk in Solaris (including OpenSolaris, Illumos, Unleashed and whatnot...), is the ancient first edition version. Whereas the "new" secound edition (from 1985(!)) of awk, which some of my scripts require, in called nawk. There are various ways around this issue, one method is to just change all occurances of "awk" to "nawk" in your local bin directory:
for file in $HOME/bin; do sed -i 's/awk/nawk/g' $file; done
Pretty much every modern UNIX version supports the -i flag to sed, as does these BSD's. However, unlike all the rest, FreeBSD and DragonFly BSD's version of sed requires an extra parameter when you use this flag (naturally this syntax breaks compatibility with other sed versions). One way to work around this issue is to change all occurances of "sed -i" to "sed -i ''" in your local bin directory:
for file in $HOME/bin; do sed -i '' "s/sed -i/sed -i ''/g" $file; done
If you are working on a non-graphical UNIX system, your shell configuration should go in ~/.profile, not ~/.bashrc. If you are planning to work on both a graphical desktop, and the text based console (aka tty), you can put the configuration in ~/.profile, and source that file in ~/.bashrc:
Of course you may be using a different shell then bash. Type ps $$ to find out, and read that shells manpage to find out how to configure it. (ps: most non-graphical shells read ~/.profile, but not all, zsh for instance expect the non-graphical configuration to be in ~/.zprofile)
The PATH and MANPATH lines above should go in ~/config/settings/profile.
My scripts should work just fine on these systems, but none of these commercial systems have been tested. (if you give me a million bucks I might be persuaded to do this...) If you are having problems check out the caviats above, and perhaps also check out the v7 port of these scripts, to see how to run such commands on ancient UNIX.
Even though Microsoft is decidedly not UNIX, it is possible to run UNIX software on their operating systems, through Cygwin for Windows and other solutions. This is untested however, and will remain so, if I have anything to say about it...