I am starting to accumulate a few scripts that I working on to replace operational scripts and to have a few for my personal usage. I am not an admin, just an operator.
They are currently located inside the /tmp folder. I know they should not be there but since we have no system admin (someone was named for it but has no experience and almost no knowledge at all) and that the system is somewhat left on its own (no one is maintaining it except for system/database upgrades done by an external company), we were never told what the standards are.
The operational scripts we are using have been created like 10+ years ago by someone who has no script/standards knowledge (still doesn't) and hasn't put any validations, protections, support coding, ... at all. They haven't been updated since and are prone to a lot of problems due to operator mistakes. I want to gradually change this, improve and secure them. I am learning scripts to do this (which has been accepted as a project).
To move my scripts into a more secured location, I want to know what are the usual standards related to where user scripts should be located.
Sorry, scottn, i would never put a script (or anything else i wrote) to /usr/bin.
/usr/bin is the place for the system binaries and provided by the OS vendor. If you put anything there you run a (small but existing) chance that one of the following updates puts an OS binary there with the same name as your utility, overwriting your script. Better leave the systems directory untouched.
/usr/local/bin is a different case because it is the place to put local extensions to the OS. This is a good place to put your utility.
I think an even better way is to create a script-set with all of your scripts (ideally to be installed via installp) and have a separate directory where you install all your scripts. For instance a directory /usr/local/bin/<something>, where you put all your scripts. If you create new scripts or change existing ones you can simply repackage them to another version of your script-set and update the system with it.
Another recommended technique: You probably have a lot of common tasks to do in your scripts to make them as robust as possible: You probably write some kind of log as the script executes so that if the script crashes you could find out why and where. You probably write some temporary files so you might want to check before if there is enough space left on the filesystem to do so and you might want to clean your temp files afterwards. You probably want to set a common environment at the scripts start to avoid the "cron problem number one": a script works perfectly from commandline but fails when called from cron because it uses the login shells environment implicitly.
Write functions for these common tasks and put them in separate files. Korn shells allows to use external functions and to search for them via the FPATH-variable, a device similar to the PATH-variable for executables. I have all my (~50) functions in a directory /usr/local/lob/ksh and set the FPATH variable to this directory. This way i make sure all the functions are found.
My own script package creates/updates the following directories:
/usr/local/etc - configuration files for some scripts
/usr/local/log - log files my scrpts write
/usr/local/lib/ksh - ksh functions i rely on
/usr/local/bin/ksh - scripts themselves
in my company, scripts for maintenance, monitoring, reporting and similar are in /opt/scripts and logging into /var/tmp/output. The scripts themselves are linked into /usr/local/bin only if we want them to be user-executable (i.e. all non-intrusive scripts) and have a server-specific response file, that exports variables, IPs, and whatever might be required, that is called by the scripts and maintained with every major system change in /opt/scripts/local. Works perfectly fine for us.
Another good habit at this point is to put your scripts in a revision control system, such as "Subversion". This protects you from the case when you (or someone else) modifies a script then can't work out what they've changed or how to get back to the working version.