Shells and execution

From Helpful
Jump to: navigation, search
Linux-related notes
Linux user notes

Shell, admin, and both:

Shell - command line and bash notes · shell login - profiles and scripts · Shells and execution ·· find and xargs and parallel · screen and tmux
Linux admin - disk and filesystem · users and permissions · Debugging · security enhanced linux · health and statistics · kernel modules · YP notes · unsorted and muck
Logging and graphing - Logging · RRDtool and munin notes
Network admin - Firewalling and other packet stuff ·

Remote desktops
VNC notes
XDMCP notes

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

restofhashbangline restofarguments

For example:

print "now it'll be run with python"


#!/usr/bin/awk -f
# -f is the awk option for 'take commands from following filename'
# 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

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:

#!/usr/bin/env perl


#!/usr/bin/env bash

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)

Env, upsides

  • 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