A humanities professional's guide to the CLI

As part of my Library Science Masters Program, I'm taking a Digital Preservation course to better learn how to steward and archive cultural heritage that is born-digital or represents a digitized version of a physical object to allow the public to enjoy it in ways they might not otherwise be able to, like the full text of the Book of Kells online.

We're learning how to use digital archiving tools, specifically Sigfried, DROID and JHOVE. My classmates have a range of backgrounds, and they vary in experience with a computer Command Line Interface (CLI). Much like if we approach a program that has an icon like this 💾, we can safely infer that pressing this button will save whatever changes to a file or digital object that have been made recently by that program. CLIs also have a set of common user experience, or UX vocabulary, though a humanities professional might not be familiar with those patterns. This post is a brief overview of the kinds of user interface patterns you're likely to encounter with CLI tools, in the hope that your experimentation with tools like Sigfried is more focused, less frustrating, and generally more successful.

Generally I avoid humanizing computers, because I think it's dangerous to think of computers and software as sentient in a time of rampant misinformation both about and driven by LLM based tools. A broad overview of these dangers is summarized in a thoroughly researched talk given at the Iowa Library Association 2025 conference by Nausicaa L. Rose. But in this guide I will use a metaphor of a program invoked using the CLI as a person, because I think it creates conceptual clarity around which tools will respond to which commands.

---

CLI sentence structure

Many of my classmates have a background in various non-English languages, and either speak English as a second language or have experience studying linguistics. Much like when learning a Romance language, because I speak French I can infer quite a lot about the sentence structure of other Romance languages and use those patterns to more quickly acquire the language. Here is a common sentence structure for a CLI.

We know that at their essence, computer programs are a list of instructions for a machine. The first word of any CLI command is the computer program that we are speaking our sentence to. I'll use Sigfried as an example, which is a very fast tool for analyzing large batches of digital objects in one go. You can think of a CLI command as an imperative sentence directed at our pal, Sigfried.

sf

You can just call sf, and like any person, if you call their name and say nothing else, they will ask "right yeah, what do you want?" but in computer-ese.

2026-03-17 11:44:28 :: sf :: sf.go:466: [FATAL] expecting one or more file or directory arguments (or '-' to scan stdin)

Sigfried is telling us how it likes to receive instructions, which a well designed CLI should do, albeit in words that are not humanities professional friendly. This brings us to another layer of our sentence diagram; CLI tools often require an input, or argument, in order to do anything. We didn't supply an argument when calling up Sigfried, so he helpfully informed us what he needs to do something for us. He's looking for a file name or a folder name, which makes sense given this tool is intended to analyze files. Sf needs to know what files to analyze.

Not all CLIs are designed with user happiness in mind, so don't worry or feel bad about yourself if you're struggling to figure out what it wants. One of my old jobs was literally on a "Developer Experience Team" whose concern was making sure tools like Sigfried were painless for the rest of my company to use so they wouldn't have to waste time making sense of inscrutable tools. That's how common difficult tools are in the computing (and frankly, the entirety of the) world.

Now, if we can't understand what the tools is telling us it needs, how can we know what else we can ask the tool? This is the sentence structure to ask a tool what vocabulary it understands:

sf --help

You use two dashes when giving a CLI an instruction with the full word. You can also use an abbreviated version with a single dash like so:

sf -h

This sentence structure is common across most CLI tools. Two dashes for a full word, and one dash for the abbreviated version. How do we know what abbreviations work? After we ask Sigfried for help, he should tell us, with this:

Usage of sf:
  -coe
    	continue on fatal errors during directory walks (this may result in directories being skipped)
  -conf string
    	set the configuration file
  -csv
    	CSV output format

et cetera

Note the entry for -conf, it tells us that we also need to include a string of characters with this command. That's a common UX pattern in vocab, but I won't dive in to that now since the Sigfried docs can be referenced for that.

I will direct you to another "person" that we can give instructions to, the manual tool. We can think of the manual tool as a kind of librarian for dictionaries of what CLI vocabulary each program speaks. Early computers counted memory and storage in the kilobytes and megabytes, so to conserve precious space, it was common to abbreviate words, commands and folder names. Those naming conventions have persisted into the age of fiftyjillion quad core GPU magic. So to ask the manual "librarian" for help, you can call the librarian's name, and then tell it what set of vocabulary you'd like to see:

man sf

And yes, many jokes have been made that this looks like we're telling a man something about sf. Some friends have configured their terminals to use "woman" instead of "man" to invoke this program which I think is pretty funny.

In this case, there isn't a manual entry for sf. But that's okay! Many other tools you may encounter will. Generally when I encounter a new CLI tool, the first thing I do is to ask it for --help. For more complex CLI tools, I can add the --help several layers in, for example:

sf -csv -help

And sometimes this will return more specific vocabulary that Sigfried understands when I am asking for its output in a .csv. I did need to refer to Sigfried's docs to do this, specifically this page under the "Save output" heading.

But will I break something?

I mean, it's possible. The thing with computers is that they are very literal, and unless the program has been instructed to prompt you with an "are you sure you want to do that?" message, the program does what it's told.

With that said, filesystems won't let you do anything truly dangerous. If you want to do something dangerous, it makes you prepend the CLI instruction with "sudo". That's the punchline of this xkcd joke, as it happens! Perhaps that particular strip makes sense for the first time in years, who knows.

So! If you are afraid of breaking something, don't ever ever use the sudo command. I tell you this to (hopefully) help reassure that you won't do serious damage as you experiment, because the filesystem won't let you.

Another dangerous command that you should avoid if you are afraid of breaking something is the "rm" command. This stands for "remove" and will delete whatever file you place after the command, like so:

rm delete_me.txt

As long as you refrain from using these two commands, you should be good to go. Have fun exploring!