Sometimes you want a backtrace or a core dump from a process that you do not want to stall. This could concern a multithreaded application of which some threads are still doing important work (like handling customer calls). Firing up gdb would halt the process for as long as you're getting info, and raising a SIGABRT to get a core dump has the negative side-effect of killing the process. Neither is acceptable in a production environment.

In comes the handy gdb(1) option -ex. See this hanging.c example that we will examine while leaving it running.

int c ...

After disk failure on our company music server, I lost my enqueue-some-random-music-script.

That shan't happen again. So here, for my own enjoyment: autoenq.sh

#!/bin/sh
enqueue_app="mocp -a"
music_glob="*.mp3"
music_path="`dirname "$0"`"
list_path="$music_path/.autoenq.list"

if [ "$*" = "-c" ]; then
        # Create list of all files
        find . -type f -iname "$music_glob" > "$list_path.tmp" 2>/dev/null # no lost+found
        # Create list of all dirs that have files
        cat "$list_path.tmp" | sed -e 's/\/[^\/]*$//' | sort | uniq > "$list_path"
        exit 0
fi

args="`echo "$*" | sed -e "s/['\\\\]//g"`" # no backslashes and single quotes please
args="`echo "$args" | sed -e 's/[[:blank:]]\+/.*/g ...

If you use ssh to run commands remotely, you may have run into the problem that you need an extra layer of escaping.

Let's say you have application myapp that for some reason only runs on host myserver. If you have functional ssh keys to log onto myserver it can be helpful to create a myapp wrapper on your desktop. After all, this:

$ myapp myargs

... is far more convenient than doing this:

$ ssh myserver
$ myapp myargs
$ logout

(Especially if you want to do stuff with stdin and stdout.)

The naive approach to /usr/local/bin/myapp is this:

#!/bin ...

Suppose you have an is_enabled boolean in your Django model.

class Rule(models.Model):
    is_enabled = models.BooleanField(blank=True)
    # other exciting fields here

And now imagine you want to negate the is_enabled values. Something you would easily do in SQL, with: UPDATE myapp_rule SET is_enabled = NOT is_enabled;

The Django F-syntax is nice, and looks like it should be up for the task.

Let's sum up a couple of attempts:

Rule.objects.update(is_enabled=(not F('is_enabled')))

No! You get this:
UPDATE myapp_rule SET is_enabled = true;

Rule.objects.update(is_enabled=(True ^ F('is_enabled')))

No! You get this:
unsupported operand type ...