Gist

calibre css file

2026-10-20T00:00:00-05:00

Motivation

Calibre viewer can be configured with a custom css style. This is done in

Calibre -> Preferences -> Styles

Which presents you with a css file to edit using the calibre file editor. The editor is plain and limiting. It is much more convenient to use a proper editor to edit a local file for this purpose. Unfortunately, calibre does not allow this as an option. The following thread Custom CSS Stylesheets for Calibre's Viewer on www.mobileread.com contains lots of useful css code, but using the default calibre file editor is extremely painful, not least of which is because you have to open and close it every time you wish to make an edit.

Solution

The file calibre-css.sh contains a shell script to update the calibre css stylesheet using a css file of your choice. Edit the file calibre-css.sh and set CSS_FILE and CALIBRE_CONFIG_DIRECTORY accordingly. CSS_FILE is the local css file you wish to use. CALIBRE_CONFIG_DIRECTORY is the default calibre configuration location, this is set to system default.

Now you can run calibre-css.sh to inject your css stylesheet file into calibre. NOTE: your calibre viewer should not be running when you do this, since we are changing the viewers stylesheet.

All the work in calibre-css.sh is done by a one liner, the last line of the file, which is explained below:

jq --arg val "$(cat "$CSS_FILE")" '."session_data"."user_stylesheet" = $val' "$config_file" >"$tmp" && mv "$tmp" "$config_file"

--arg val "$(cat "$CSS_FILE")" : sets the variable val to the contents of $CSS_FILE

'."session_data"."user_stylesheet" = $val' : jq program to run. It assigns the variable "session_data"."user_stylesheet" to the value of the variable val, i.e. the contents of $CSS_FILE

"$config_file" : is the source file

> "$tmp" : send the output of jq to a temporary file

&& mv "$tmp" "$config_file" : and if all goes well replace the original with the temporary file

In closing calibre.css is the style sheet I use. It's an amalgamation of various sources, that mimics the solarized color scheme.

The problem of url routing.

2026-10-19T00:00:00-05:00

Motivation

One eventually stumbles into the problem of routing a url to it's intended program. The operating system configures some defaults, but they are often inadequate. The typical solution is to copy the url into the system clipboard and then paste it into the desired program. This is better but still limiting. A more sophisticated solution is to use a clipboard manager to route the copied url. Two such tools are parcellite and xclip, and they work well. My preferred solution is dmenu and a shell script, which is what this post is about. This solution is leaner and offers more control, at the expense of doing some shell scripting.

dmenu

dmenu is a menu tool from suckless tools. It gives the user a menu and echoes the choice. A shell script can grab and process the choice echoed by dmenu, in effect routing a url to the program chosen by the user. One can do this by creating a script browser-launcher.sh and making it the default browser.

#!/bin/sh
# browser-launcher.sh

# if no url provided, use the one in the clipboard

if ! [ "$1" ]; then
    set -- "$(xclip -o -selection clipboard)"

fi

browser=$(
    dmenu -l 5 -p "Open with:" <<-EOF
        w3m
        feh
        firefox
        mkebook
        yt-dlp
        chromium
    EOF
)

# $1 contains the url to route
# $browser contains the menu item chosen by the user, i.e. the program to send the url to

# send $1 to $browser program the background
{
    case "$browser" in
      w3m)
           # ${1%%\?*} is necessary to strip parameter options, or w3m exits prematurely
           urxvt -e sh -c "w3m ${1%%\?*}" ;;
      feh) feh "$1" ;;
      firefox) firefox "$1" ;;
      mkebook) mkebook "$1" ;;
      yt-dlp) yt-dlp "$1" ;;
      chromium) chromium "$1" ;;
      *) # default option
         exit 0
      ;;
    esac
} &

To make browser-launcher.sh the default browser copy the file /usr/share/applications/firefox-esr.desktop to $HOME/.local/share/applications/browser-launcher.desktop. Edit the new file changing the line starting with Exec to Exec=browser-launcher.sh %u. This assumes that browser-launcher.sh is in the $PATH Then we make it the default browser by

xdg-settings set default-web-browser browser-launcher.desktop

One can also setup a hotkey to launch browser-launcher.sh.

The file browser-launcher.sh in the example above is simple and is meant as a template to demonstrate proof of concept. Since it's a shell script one can do some sophisticated processing. This is where the approach proves superior to a clipboard manager. Below is a (slightly) more complicated case. We process an x.com url to extract the user name and launch firefox with the new url pointing to the users threadreader.com page.

firefox-threadreader)
   url=$1
   url=${url#http://}
   url=${url#https://}
   url=${url#*/}
   url=${url%%/*}
   firefox "https://threadreaderapp.com/user/$url"
   ;;

fzf

fzf offers a similar capability to dmenu with the benefit of fuzzy searching through menu items. The limitation is the menu can only be deployed in the terminal which is limiting.

Comparing awk, R and python

2026-08-21T00:00:00-05:00

Motivation.

Now and then one wants to know the amount of RAM used by a particular program. With multiprocessing this is harder than it looks. There's even a cli tool smem. It's a nice tool written in Python. Making it painfully slow for interactive cli use. The proper way to do this is with cgroups. This assumes you know ahead of time the program you want to monitor and you have cgroups available and setup.

Solution

To that end lets script this, in the process we compare awk, R, and python. The command pgrep -f command_name will spit out the desired process PID's, which we pass on to ps. Like so:

# shell function
smem() {
    ps -o "uss,rss,pss" $(pgrep -f "$1")
}

So for example smem firefox will spit out a table listing USS, RSS and PSS RAM use of each firefox thread. All that's left is to sum each column to get the totals and we're done. Note pgrep matches a regex, so you might want to verify what you are matching. A better alternative would be

smem() {
    local MATCH=$(pgrep -f "$1")
    ps -o "command" $MATCH
    ps -o "uss,rss,pss" $MATCH
}

The simplest way to sum the columns of the table is to write a script. The scripts are written in awk, R and Python. They all do the same thing. They sum every column of a table. For example:

$ A=$(cat <<EOF
A B
1 2
3 4
EOF
)

$ echo "$A" | table_total.awk
         A          B
         4          6

table_total.awk takes two optional arguments, the first one is input units, and the second one is output unit format.

$ echo "$A" | table_total.awk 1000

         A          B
      4000       6000

$ echo "$A"  | table_total.awk 1000 si

         A          B
      4.0k       6.0k

The final command (in smem.sh) becomes:

# Display output in binary units
smem_awk() {
    ps -o "uss,rss,pss" $(pgrep -f "$1") | table_total.awk 1024 iec

}

# Example: chromium with no tabs open uses 308M of unique RAM, but 1.3G of non-unique RAM.
$ smem_awk chrome

       USS        RSS        PSS
      308M       1.3G       525M

The Python script is short and elegant. The R script is also short, but ugly. The awk script is lengthy. Lets compare performance.

$ T=$(cat <<EOF
USS   RSS   PSS
 3008  7740  3297
 1680  6188  1904
   44  4164   134
 2184  3816  2472
   52  4288   147
EOF
)

# side note: table_total.awk is calling numfmt which seems a bit off in some cases.
# Example, converting 25.6Mi gives 26Mi.
$ numfmt --from-unit=$((1<<20)) --to=iec-i 25.6
26Mi

$ time table_total.awk 1024 iec-i <<<"$T"
       USS        RSS        PSS
     6.9Mi       26Mi      7.8Mi

real    0m0.007s
user    0m0.006s
sys 0m0.001s

$ time table_total.R 1024 iec <<<"$T"
      USS      RSS      PSS
  6.8 MiB 25.6 MiB  7.8 MiB

real    0m0.211s
user    0m0.551s
sys 0m0.032s

$ time table_total.py 1024 iec <<<"$T"
       USS         RSS         PSS
   6.8 MiB    25.6 MiB     7.8 MiB

real    0m0.451s
user    0m0.781s
sys 0m0.068s

Python is painfully slow at almost half a second. R is a bit slow but still snappy. Awk is blazing fast. Guess which I'll be using.

To be fair this is an apples to oranges comparison. The reason the Python version so clean, concise and simple is because it's loading some powerful libraries to do the work. Were the Python code written in the same manner as awk it would have a different performance profile. It would also be longer and uglier.

What happens at scale?

What if our table is massive? Spoiler: Python comes out significantly ahead.

To that effect lets write a script to generate a table of random integers between 0 and 100:

# a 3 by 4 table
$ table_gen.py 3 4
 A  B  C  D
59 42 41 65
 7  2 18 80
26 67 67 17

# table with 2 million rows and 5 columns
$ table_gen.py 2000000 5 > table.txt

$ time table_total.awk < table.txt
         A          B          C          D          E
  98951126   99034755   98973663   98991072   98951685

real    0m2.844s
user    0m2.836s
sys     0m0.008s

$ time table_total.R < table.txt
        A        B        C        D        E
 98951126 99034755 98973663 98991072 98951685

real    0m2.241s
user    0m2.519s
sys     0m0.161s

$ time table_total.py < table.txt
         A           B           C           D           E
  98951126    99034755    98973663    98991072    98951685

real    0m1.180s
user    0m1.283s
sys     0m0.340s

The file table.txt only takes up 30M. Once you get into even larger tables python is a clear winner, but the startup cost of python is much too high for a quick interactive system tool. (At least the way I implemented it.)

We could also process the table in parallel across different cpu cores. With 4 cores, using gnu parallel,

$ time parallel --pipe-part -a table.txt --block -1 table_total.awk | table_total.awk
         A          B          C          D          E
  98951126   99034755   98973663   98991072   98951685

real    0m0.866s
user    0m2.989s
sys     0m0.077s

The Python and R scripts would need to be modified to handle missing headers to do this properly. Note that while the real time is lower than the Python script, the user time is much higher due to utilizing multiple cpu cores. In other words the Python script is much more efficient, and parallelizing should yield a greater benefit. Due to a quirk in awk (namely char + digit = digit, i.e 'A' + 2 = 2), we can do

$ time parallel --pipe-part -a table.txt --block -1 table_total.py  | table_total.awk
  98951126   99034755   98973663   98991072   98951685

real    0m0.948s
user    0m2.852s
sys     0m0.426s

Note the missing header in the output.

This is not faster than parallelizing awk alone, because of Python startup cost. But if we were to scale up the table size yet again, we should see performance benefits.