Stephan Sokolow's Blog

NOTE: While none of the significant elements of this approach require zsh, the formatting syntax and mechanism for updating a prompt dynamically differ between zsh and bash. See the end for a version with zsh-specific bits stripped out.

For a while, I’ve been using a variation on this zsh prompt tweak to get a pretty indication that I’m in a virtualenv. However, I was never quite satisfied with it for two reasons:

1. It only works for virtualenvs activated through virtualenvwrapper
2. It goes away if I launch a child shell… which is when I’m most likely to be confused and needing an indicator.

The solution was obvious: Instead of using a virtualenvwrapper hook, put something in my .zshrc which will detect virtualenvs opened through any means.

For those who just want something to copy-paste, here’s what I came up with:

zsh_virtualenv_prompt() {
    # If not in a virtualenv, print nothing
    [[ "$VIRTUAL_ENV" == "" ]] && return

    # Support both ~/.virtualenvs/<name> and <name>/venv
    local venv_name="${VIRTUAL_ENV##*/}"
    if [[ "$venv_name" == "venv" ]]; then
        venv_name=${VIRTUAL_ENV%/*}
        venv_name=${venv_name##*/}
    fi

    # Distinguish between the shell where the virtualenv was activated and its
    # children
    if typeset -f deactivate >/dev/null; then
        echo "[%F{green}${venv_name}%f] "
    else
        echo "<%F{green}${venv_name}%f> "
    fi
}

setopt PROMPT_SUBST PROMPT_PERCENT

# Display a "we are in a virtualenv" indicator that works in child shells too
VIRTUAL_ENV_DISABLE_PROMPT=1
RPS1='$(zsh_virtualenv_prompt)'

First, notice the use of VIRTUAL_ENV_DISABLE_PROMPT. This is because activate will prepend a less attractive indicator to PS1 that also goes away in child shells.

(Just make sure you remove any PS1="$_OLD_VIRTUAL_PS1" you might have added to postactivate or you’ll have no prompt after typing workon projname and be very confused.)

Second, note the use of PROMPT_SUBST. This is actually shared with my code for adding git branch information to PS1, PS2, and PS3 because profiling showed it to be faster than using a precmd function.

Third, note the single quotes for RPS1. That’s necessary to defer the invocation of $(check_virtualenv) so PROMPT_SUBST can see it.

I also added a couple of convenience features:

• I have had a history of virtualenvwrapper not getting along with Python 3.x, so some of my projects have their virtualenvs at ~/src/<name>/venv rather than ~/.virtualenvs/<name>. This script will display <name> in the prompt either way.
• If I’m in a child shell where the deactivate function isn’t available, the prompt will show <foo> rather than [foo] to make me aware of that.

Aside from that, it’s just ordinary efforts to avoid performing disk I/O or use $() in something that’s going to get run every time the prompt is displayed, and a function structured so the most common code path executes the fewest statements.

While this StackOverflow answer cautions against using VIRTUAL_ENV to detect virtualenvs, its reasoning doesn’t apply here, because it’s talking about detecting whether your Python script is running under the influence of a virtualenv, regardless of whether activate was used to achieve that. The purpose of this indicator, on the other hand, is specifically to detect the effects of activate so I don’t run something like manage.py runserver or pip install in the wrong context.

Bash Version

bash_virtualenv_prompt() {
    # If not in a virtualenv, print nothing
    [[ "$VIRTUAL_ENV" == "" ]] && return

    # Support both ~/.virtualenvs/<name> and <name>/venv
    local venv_name="${VIRTUAL_ENV##*/}"
    if [[ "$venv_name" == "venv" ]]; then
        venv_name=${VIRTUAL_ENV%/*}
        venv_name=${venv_name##*/}
    fi

    # Distinguish between the shell where the virtualenv was activated and its
    # children
    if typeset -f deactivate >/dev/null; then
        echo "[${venv_name}] "
    else
        echo "<${venv_name}> "
    fi
}

# Display a "we are in a virtualenv" indicator that works in child shells too
VIRTUAL_ENV_DISABLE_PROMPT=1
PS1='$(bash_virtualenv_prompt)'"$PS1"

It’s almost identical to the zsh version, but the following functions which zsh provides for free are left to the reader in the bash version:

• Implementing a right-aligned chunk of the prompt which stays properly positioned if you resize your terminal.
• Using tput to retrieve the colour-setting escape sequences for your terminal and then caching them in a variable so you’re neither hard-coding for a specific terminal type nor performing multiple subprocess calls each time you display your prompt.

A.K.A. How to get and compare timestamps without external commands in shell script (and without even invoking subshells in Zsh)

I love the fortune command. It’s a charming little addition to each new tab I open… until something (like a nightly backup) has blown away my disk cache or a runaway memory leak is causing thrashing. Then, it’s just a big delay in getting to what I want to do.

The obvious solution to any non-shell programmer is to time everything and invoke fortune only if it’s not already taking too long, but shell script complicates that by having so few builtins. We don’t want to invoke an external process, because that would defeat the point of making fortune conditional, and we don’t want to invoke a subshell because, if we’re thrashing because of memory contention, that’ll also make things worse.

It turns out that bash 4.2 and above can get us half-way there by using a subshell to invoke the printf builtin with the %(%s)T token, but Zsh has a clever little solution that even reuses code that we’re going to need anyway: prompt substitutions!

Here’s the gist of how to pull it off:

# Top of .zshrc
local start_time="${(%):-"%D{%s}"}"

# -- Do all my .zshrc stuff here

local end_time="${(%):-"%D{%s}"}"
if [[ $(( end_time - start_time )) < 2 ]]; then
    if (( $+commands[fortune] )); then
        fortune
    fi
else
    echo "Skipping fortune (slow startup)"
fi

This is a standard “subtract start time from end time to get how long it took, then compare it to a threshold” check, so the only part that should need to be changed in bash is using start_time="$(printf "%(%s)T")". Instead, let’s pick apart how the Zsh version works:

1. We start with a bog standard ${VAR:-DEFAULT} parameter expansion however, unlike bash, Zsh does consider ${:-always default} to be valid syntax.
2. The (%) on the left-hand side is a special magic flag, similar to the (?i) syntax used for inline flag-setting in some regular expression engines. It enables prompt expansion of both the (nonexistent) variable’s contents and the fallback value.
3. %D{...} is Zsh’s prompt expansion placeholder for putting strftime (man strftime(3)) timestamps into your prompt.
4. %s is the strftime token for “seconds since the epoch”
5. You have to quote the %D{...} or the ${...} consumes the closing curly brace too eagerly.

That’s the big magic thing. A way to write an equivalent to time(2) from the C standard library in pure Zsh script with no use of $(...) or zmodload and, since we’re using prompt expansion to do it, the only thing we might not already have needed to load into memory is the code for the %D{...} expansion token.

(Unfortunately, there’s no way to get sub-second precision with this approach, so the only two useful threshold values for a well-optimized zshrc are probably “1 second” and “2 seconds”.)

Now for that odd (( $+commands[fortune] )) way of checking for the presence of the fortune command. What’s up with that?

Well, it’s actually a micro-optimization that I use in my zsh-specific scripts. According to this guy’s tests, it runs in half the time the other options take and, in my own tests using his test scripts, I found that, depending on the circumstances, that could go as far as one tenth of the others, and that the others vary wildly relative to each other. (On runs where $+commands is 7 to 10 times as fast as type and which, hash is sometimes twice as fast as type or which and sometimes half as fast.)

Normally, this would be a moot point because any of the portable ways of checking for the existence of a command via a subshell and a builtin would be far too quick for it to matter (ie. I do it just for the heck of it) but, in this case, it felt appropriate.

(Another unnecessary micro-optimization that I didn’t use here was preferring [[ ]] over [ ] in my zshrc scripts. My tests found a million runs of [[ "$PWD" == "$HOME" ]] to take about 1.4 seconds, while a million runs of [ "$PWD" = "$HOME" ] took about 4.2 seconds.)

Recently, I’ve been trying to make my coding environment snappier, and one thing I was never happy with was how slow my .zshrc is.

Now, don’t get me wrong, I’m not one of those people using oh-my-zsh with a ton of plugins and seeing 15-second waits for my shell to start… but I do want a new tab to be ready in a second or less.

So, I slapped zmodload zsh/zprof onto the top of my .zshrc, opened a new tab, and ran zprof | less …and 50% of the wait was in sourcing virtualenvwrapper, which I don’t feel like reinventing.

Time to take a lesson from the improvements I’ve been making to my .vimrc. Specifically, the { 'on': ['CommandA', 'CommandB'] } option hanging off the end of various lines for my plugin loader.

A little experimentation later and I came up with this construct:

function init_virtualenvwrapper {
    # Don't do anything if it's already loaded
    type virtualenvwrapper_workon_help &>/dev/null && return

    # ------------------------------------------------
    # normal stuff to load virtualenvwrapper goes here
    # ------------------------------------------------
}

for cmd in workon mkproject mkvirtualenv; do
    function $cmd {
        unset -f "$0"
        init_virtualenvwrapper
        "$0" "$@"
    }
done

For those not familiar with shell scripting, I’ll clarify.

For each shell function or command that I want to trigger deferred loading, I create a function with the same name that does the following:

1. “Delete” itself so it won’t interfere with what virtualenvwrapper is going to set up. (You want to do this first to avoid removing what virtualenvwrapper just created)
2. Call the virtualenvwrapper setup code to load the real command.
3. init_virtualenvwrapper starts by checking for some side-effect of having been run before and exits early if that’s the case. (This keeps mkproject from re-doing what workon already did, or vice-versa.)
4. Call the actual command and pass through any arguments.

Doing this means that:

1. Your .zshrc or .bashrc startup time only pays the price for declaring a few shell functions. (And, if that gets too heavy for some reason, you could move init_virtualenvwrapper into another file and source it on demand.)
2. Your first call to a wrapped command like workon will take longer. (eg. if it was adding two seconds to your shell start time, then your first call to it will take two seconds longer.)
3. Subsequent calls to that or any other command sharing the same init_virtualenvwrapper will be as quick as usual.

Unfortunately, this design is actually Zsh-specific, which sucks for me because this is a file I share between .zshrc and .bashrc:

1. Bash doesn’t support using a variable for a function name, so you can’t use a for loop. You’ll just get `$cmd': not a valid identifier.
2. In my testing, functions didn’t set $0 in bash, so this will actually execute bash "$@", bringing you back to where you started, while zsh doesn’t set the FUNCNAME array variable that bash uses.

So, if you want to support both, here’s the most concise form I was able to put together:

function init_virtualenvwrapper {
    local _cmdname="$1"
    shift
    unset -f "$_cmdname"

    # Don't do anything if it's already loaded
    if ! type virtualenvwrapper_workon_help &>/dev/null; then
            # ----------------------------------------
            # normal stuff to load virtualenvwrapper
            # ----------------------------------------
    fi

    "$_cmdname" "$@"
}
# }}}

function workon {
    init_virtualenvwrapper "${FUNCNAME[0]:-$0}" "$@"
}
function mkproject {
    init_virtualenvwrapper "${FUNCNAME[0]:-$0}" "$@"
}
function mkvirtualenv {
    init_virtualenvwrapper "${FUNCNAME[0]:-$0}" "$@"
}

Anyway, I hope this helps to inspire anyone else who’s suffering from slow shell startup times.

UPDATE: And now, shortly after writing that, I discover that someone else went to the trouble of using eval to provide a nice API on top of this trick and put it up on GitHub as sandboxd. From that name, I can see why i didn’t find it before.

If you’ve ever downloaded a .cbz file using Firefox and then tried to click it in the downloads panel, you might have noticed that Firefox ignores the association for the .cbz extension and instead opens it as a .zip file. (This isn’t the only situation where this happens and I filed a bug about it a year ago.)

I never got around to looking into why it doesn’t make the same mistake with .odt documents, which are also Zip files with a specialized extension, but I think you can see why I wouldn’t like it.

Here’s a quick little script that can be set as the Zip handler on a KDE-based desktop which will hand over to Ark under normal circumstances but, if it receives a file with a .cbz extension, will pop up a Yes/No dialog offering to open in Comix instead.

Anything which obeys the system’s associations properly will never trigger it, because .cbz files will be associated with Comix and it won’t pop up the dialog if fed a .zip file, so it’s about the best solution one can have without fixing Firefox.

This approach could also be easily extended to application/octet-stream to work around the other situation where I’ve seen this causing problems. (Patreon serving up image files with the wrong mimetype, if I remember correctly.)

When it comes to me and organizing images, GQView (now Geeqie) has always been a “best of a bunch of bad options” sort of thing and, with my move off Kubuntu 14.04 LTS, it’s become downright unusable in some cases. (eg. Freezing up at 100% CPU for several minutes to load certain collections)

As a result, I’ve been pushed to prioritize my efforts to replace at least the bare minimum subset of that functionality and, since I don’t want to rely on gtk3-mushrooms to make my own creations tolerable to me and Rust doesn’t have mature Qt bindings, that means PyQt5.

It’s not perfect (Qt doesn’t have incremental loading like GdkPixbufLoader, so I have to rely more heavily on my prototype code for asynchronously loading a bunch of upcoming images ahead in the background while I dawdle looking at the current one) but it’ll have to do… and I’ve filed a bug about that.

Now Qt has always been weird about how to get a displayed image to preserve its aspect ratio properly. It’s probably the one really glaring oversight in an otherwise very nicely designed and documented set of APIs. Given how much I had to fiddle around with things, I decided that I definitely wanted to share what I came up with.

What made it more difficult is that I’ve always wanted a GQView-alike which also displays animated GIFs with their animation, and Qt doesn’t have a unified solution for that. (QImage handles static images and QMovie handles GIF and MNG, but not actual movies, which you need to use the multimedia backend for.)

It turns out that getting smooth upscaling with QMovie is a tricky thing in itself because it’s very easy to accidentally build a widget tree that does the upscaling at a point in the pipeline where fast/ugly upscaling gets used, so a big thanks to Spencer on StackOverflow who figured it out.

Anyway, enough talk. Here’s the code:

(Yeah. I was too eager to post it, so this prototype hasn’t actually been split into the design which allows me to put the cache after the images get decoded. Still, it should be useful for most people.)