Difference between revisions of "Shells and execution"

From Helpful
Jump to: navigation, search
m (--)
Line 106: Line 106:
and what you want is  {{inlinecode|rm -- -v}}
and what you want is  {{inlinecode|rm -- -v}}
This is something commands choose to adhere to when intepreting the argument array.
Various (but not all) bash builtins understand --
Various (but not all) bash builtins understand --

Latest revision as of 16:55, 27 November 2019

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 · Init systems and service management (upstart notes, systemd notes) · 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 text file (a.k.a. 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'
# ...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

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


Double dash is used to signify end of option argument, i.e. that only positional arguments follow (to be taken literally)

for example, if you wanted to remove a file called
, running
rm -v
would just get you a "missing operand" error, and what you want is
rm -- -v

This is something commands choose to adhere to when intepreting the argument array.

Various (but not all) bash builtins understand --

Some programs understand --

When running sub-programs, especially security-related ones, -- can be a good tool/habit to protect programs against injecting arguments.