💾 Archived View for thrig.me › tech › shell-elimination.gmi captured on 2023-06-16 at 17:19:18. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Shell Elimination

We must first define what a shell is (in the context of computing). By shell I mean the unix shell. Now it is rather difficult (but not impossible) to eliminatethe shell, so the elimination must be one of those goals aimed for but not achieved. Elimination is also a tad bit dramatic.

Why Eliminate the Shell?

    $ bash
    /bin/ksh: bash: not found

While the shell is suitable for wrangling one liners or other not-too-long bits of code, it is not a very good programming language. Relatively simple constructs are dangerous (and slow) so for me the threshold of reaching for a different language is very, very low, usually if the script gets longer than about a terminal (80x24) or has something tricky (and slow) like a while loop in it. While while can be used correctly, one might wonder how many shell scripts actually do write it correctly.

    while IFS= read -r line || [ -n "$line" ]; do
      ...

The famously unreadable Perl, by contrast, might write the above as

    while (my $line = readline) {
      ...

and if one benchmarks these loops, well, the shell is laughably slow.

Where Eliminate the Shell?

Certainly not where the shell is a good fit. Exec wrappers such as

	#!/bin/sh
	exec tmux -u new-session -A -c "$HOME" -s "${1:?need a session name}"

are a good fit for the shell. These could be shell aliases or functions, but that bloats the shell, and makes the utilities difficult to use (or test) from anywhere that is not that shell. Put these scripts in PATH, make them usable by everything. Longer scripts I rewrite in some other language (C, Common LISP, Perl, TCL). Other uses of the shell are rather subtle, though may become apparent under ktrace or when a security incident reveals that untrusted user input got passed to /bin/sh, usually via the system(3) interface. Detect and if possible eliminate or rewrite these: can a fork and exec be used instead? If not, does untrusted user input get anywhere near the system(3) calls?

CVE-2020-7247 (among too many other CVE) shows what can happen with untrusted user input getting to places it should not.

Recap

Short scripts are probably fine for /bin/sh. Like, under 20 lines.
Rewrite longer scripts. Practically any language is a better choice.
Audit for system(3) calls that can be replaced with something else.

Back to tech index

tags #ksh #sh #bash #zsh