Shells and execution
| Linux-related notes
Shell, admin, and both:
| These are primarily notes|
It won't be complete in any sense.
It exists to contain fragments of useful information.
In unices, a hashbang, or shebang, is a reference to the two characters that, if they are the first characters on the first line in an executable script, mean that script will be executed as if you were running
#!/usr/bin/python print "now it'll be run with python"
#!/usr/bin/awk -f # -f is the awk option for 'take commands from following filename' # ...to point out that this mostly just appends the hashbang line and the script filename
#!/bin/bash -x # -x means "bash, please print everything before you do it", useful in debug echo "You can make bash show what it's doing as it's doing it" sleep 1 ifconfig
It seems that exactly which part of the system handles a hashbang (and, technically, whether a space can follow the exclamation mark) may differ per OS and environment, but you can assume it always works.
When a file is executable but has no hashbang, it is run by /bin/sh(verify)
When things aren't always in the same place, hashbangs may be fragile.
You can use env instead, which finds a program independant of its path, so the only absolute path that matters is the path to env itself. For example:
Actually, the initial point of env seems to have been (verify) to modify the environment, which means you can protect specific script from knowing as much about your system.
Hardcoded path, upsides
- choice of executable does not vary with user's PATH
- specifying a specific version is less work (env allows it but not always easily)
- more portable when other systems don't have the the executable in the same place
- lets user have
'bad interpreter: no such file or directory', and an ^M at the end of the interpreter name
There are windows-style newlines in the script.
While the interpreter itself usually has no problem with that, the hashbang line should not have one. Using an editor to remove that one is usually enough, but it can sometimes be hard to find and editor that doesn't hide this newline detail. You could just run the whole script through dos2unix (or another such translator).
Run one copy of yourself / check whether program is already running
If you're checking for a copy of yourself:
- the more robust way is to actually communicate it, e.g.
- abstract sockets where possible - is like unix sockets but avoids the need for file cleanup
- linux-only, though
- unix sockets. Has footnotes related to cleanup.
- pidfile-like conastruction e.g. in /tmp. Has footnotes related to cleanup.
- if you're a network service, you can often test for a very simple known response. (But has to take a port)
- if you're graphical, you can now often assume DBus (still an assumption)
- easy but not robust/portable
- if you've set up as a service you can often test for it
- pidof myname (caveats around process naming)
- parse ps output (ps output may vary over time / between systems)
- parse /proc (not portable, may vary over time)
- use advisory locking via the filesystem
- e.g. flock
Assuming you may