Linux Troubleshooting 101-Scripting
Scripting 101
- always fully specify paths to all programs and files (input/output) inside any script. NEVER trust the PATH.
- always set any environment variables necessary to the script. Don’t trust the userid environment to be available during cron. JAVA_HOME is an example, but there are thousands of others – most scripts need fewer than 5 environment variables.
- use the -x to see what a script does. bash -x
- use built-in “verbosity” settings for any specific command; often -v or -vvvv for more output.
- Unix uses file permissions to control if a script is "executable or not. Extensions mean ZERO. Is your script permissions set to allow the userid trying to run it to see “execute” permissions?
- check the log files – client-side AND server-side.
- break down the problem inside the script to the simplest command.
- do NOT use GUI programs inside any scripts that need to run automatically. Look for the CLI version of the tool and use that instead.
- For scripting used by the public – websites – always review the code against the OWASP checklist for that language. They have a nice Top 10 list too. Guides for C, C++, Perl, Bash, Php, Python, Ruby …. try to learn from
- For bash scripting, the ABSG covers almost everything possible. For other languages, there are many, many books, websites, webpages to help.
There are many other techniques to be deployed depending on the scripting language used. Bash has a few other things like capturing interrupts, using noclobber, stuff like that, to make your scripts safer.
Perl, Python, Ruby work great with TDD – Test Driven Development. Tools for each make it easy to write tests before writing the actual code so we don’t forget about unexpected inputs. Test::More works for perl. spec is part of RoR development – cucumber is also there for Ruby. These are just examples.
