tty1

Real World Solutions: Updating Ebooks

2024-02-10T22:40:54.000Z

So far, this blog has largely been tutorials on how to use particular commands or workflows. I'll keep doing that, but I also want to highlight some real-world problems that can easily be solved with some knowledge of shell scripting and the command line.

To start off, here's how I used the find command to create a script for Nantucket E-Books to help them easily update the code for all of their books at once.

The Setup

While I didn't have the exact file structure to work from, based on Nicholas's description I was able to infer that it looked something like this:

.
├── author1
│   ├── book1
│   │   └── assets
│   │       └── js
│   └── book2
│       └── assets
│           └── js
├── author2
│   └── book1
│       └── assets
│           └── js
├── author3
│   ├── book1
│   │   └── assets
│   │       └── js
│   ├── book2
│   │   └── assets
│   │       └── js
│   └── book3
│       └── assets
│           └── js
├── author4
│   ├── book1
│   │   └── assets
│   │       └── js
│   └── book2
│       └── assets
│           └── js
└── author5
    ├── book1
    │   └── assets
    │       └── js
    ├── book2
    │   └── assets
    │       └── js
    ├── book3
    │   └── assets
    │       └── js
    └── book4
        └── assets
            └── js

Within each book's folder, the same three JavaScript files needed to be updated to the newest version.

the solution

My solution was a simple shell script:

#!/bin/sh

subdirs="$(find "$PWD" -mindepth 2 -maxdepth 2 -type d)" # Get the full paths of all second-level subdirectories

echo "$subdirs" | while read subdir; do # for each selected subdirectory, do the following
	cd "$subdir" # moves into the correct directory

	# do your actions here

done

This solution let him add the actual commands to copy the new files at the indicated location, but would make sure whatever he put there would be executed in every book's folder. For example:

cp ~/code/updated-file.js ./assets/js/file.js

The above would take the updated file and copy it to the location it belongs in each book's subdirectory.

breaking it down

Let's break this solution down a little.

To start off, I wanted to get every book's path and store it to a variable, subdirs. The find command is ideal for that purpose.

the positional "$PWD" argument specifies the containing directory to search within ($PWD is a variable that returns the current working directory). You could set this to the path of your parent directory if you like, to be able to run the script from anywhere, but I didn't know that path and figured running the command from the directory would suffice.
-type d limits results to directories only; by default, find looks for both files and directories (-type f would find files only)
-mindepth 2 makes sure results are at least two directories away from the base directory
-maxdepth 2 makes sure results are a maximum of two directories away from the base directory

Combined, -mindepth 2 and -maxdepth 2 essentially just say "find all results that are exactly two subdirectories away". In our case, this perfectly matches all book directories, since they're subdirectories of the author directories, but keeps the script from matching the assets and js directories, since those are more than two subdirectories away.

Let's test it:

/tmp/tmp.UkyqnYccbh] subdirs="$(find "$PWD" -mindepth 2 -maxdepth 2 -type d)"
/tmp/tmp.UkyqnYccbh] echo "$subdirs"
/tmp/tmp.UkyqnYccbh/author2/book1
/tmp/tmp.UkyqnYccbh/author4/book2
/tmp/tmp.UkyqnYccbh/author4/book1
/tmp/tmp.UkyqnYccbh/author1/book2
/tmp/tmp.UkyqnYccbh/author1/book1
/tmp/tmp.UkyqnYccbh/author3/book2
/tmp/tmp.UkyqnYccbh/author3/book1
/tmp/tmp.UkyqnYccbh/author3/book3
/tmp/tmp.UkyqnYccbh/author5/book4
/tmp/tmp.UkyqnYccbh/author5/book2
/tmp/tmp.UkyqnYccbh/author5/book1
/tmp/tmp.UkyqnYccbh/author5/book3

That is, indeed, all of the exact directories we want!

I run my test commands for these articles within a temporary directory, in this case /tmp/tmp.UkyqnYccbh, so that they don't interfere with the rest of my system. I use this shell alias to quickly create and enter a temporary directory when I run tempdir:

alias tempdir="cd $(mktemp -d)"

Next, we want to loop through all of these folders. In my last article, I mentioned the strategy of piping a list to a while loop, which I've done again here.

echo "$subdirs" | while read subdir; do
	# …
done

An important note is that pipes like this create subshells, meaning that any variables I set within the loop cannot affect the rest of the script. For this use case, that doesn't matter (since created files/directories will of course remain after the subshell finishes), but it's good to be aware of when adapting this script to your own purposes.

Now that we are in the loop, we'll move into the subdirectory that's currently being processed:

cd "$subdir"

Easy peasy. As we mentioned, anything else we want done while in this folder can now be added.

the results

Nicholas's immediate response?

I just updated the software and stylesheets for forty-eight e-books on the site with one command.

He's written a blog post of his own that mentions this solution, which is also worth reading. And while you're there, check out the platform, it's a great and easily accessible platform to read books for free from any device, with built-in audiobooks. It's a great project, and I'm proud to have been able to lighten the load of keeping it running.

conclusion

I'll leave off there. If you have solutions to real-world problems of your own to continue this series or a real-world problem you need help solving with the shell, I'd love if you'd send me a message! It can be like this article, where I wrote about a solution to someone else's problem, or you can write a guest article for publication on this blog.

My email (and PGP key!) are below, I'd love to talk through your ideas with you. See you next time!

moosh: the Moo Shell

2023-09-13T00:58:02.000Z

As a joke, this week I coded a Linux shell: moosh. The whole idea behind moosh is that it responds to every command with a random-length "MooOooOOo…"

So, yes, it's a joke. But let's take a look at it and see if there are any ideas about scripting we can learn along the way.

The Code

The code is pretty short, written in bash, so here is the full code:

#!/usr/bin/env bash

while true; do
	printf "$ "
	read input
	if [[ "$input" ]]; then
		echo -n "Mo"
		seq 1 $(($RANDOM % 15 + 1)) | while read n; do
			if [ "$(($RANDOM % 2))" = "0" ]; then
				echo -n "o"
			else
				echo -n "O"
			fi
		done
		echo "…"
	fi
done

We'll break this down, piece by piece.

Part 1: The Shebang

#!/usr/bin/env bash

The first line of all shell scripts follows this form. Called the shebang, it tells your system what program to use to run the file. In this case we want to use bash, but we don't have a guarantee that the bash executable will be in the same location, so pointing to a location like /bin/bash might not work on all systems.

To solve this dilemma, we can use /usr/bin/env to find the location of any executable. Another common use is to create a python script; to do so, you could use this shebang:

#!/usr/bin/env python

Before we move on, I should also cover /bin/sh.

#!/bin/sh

On a Linux (or similar) system, /bin/sh will point to a POSIX-compatible shell. On many systems, this is bash, but not all, so for greater compatibility you shouldn't use /bin/sh if you're using bash-specific features. For example, on my system I use dash as my /bin/sh, which is more minimal, but more performant.

I would usually use /bin/sh for scripting, but in this case I wanted to use the $RANDOM variable, which isn't present in all shells, so I did /usr/bin/env bash instead.

Part 2: The Infinite Loop

while true; do
    # …
done

Pretty self-explanatory what this does: while the true command succeeds (which will always be the case), the action inside the loop will be executed, effectively executing repeatedly. We're using this to keep prompting for new commands. Now, there are a couple ways, still, to break this loop:

Run the break command from the script; this exits the loop. Often people don't know how long a loop will run or exactly what condition will end it, so they'll create an infinite loop and just call break when they're done with it.
Hit ^C (ctrl + c) while the script is running. This is the approach we're expecting users to take; when they're done with moosh, they can just hit ^C and exit.

Now, let's look at what will happen endlessly inside this loop.

Part 3: Taking Input

printf "$ "
read input
if [[ "$input" ]]; then
    # …
fi

First, we want a shell prompt. We don't need anything fancy (since people can't actually do anything in this shell), so we'll just use $ as our prompt.

printf "$ "

By using printf with no arguments, we're printing out the string without a line break, so user input will happen on the same line.

Now, we want to take the user's command into a variable, input. We can use the read command for that.

read input

We don't actually care what the input is, since we're going to do the same thing regardless. But we do want to make sure there is input; we can use an if statement to check that the user did input something, and if not skip responding.

if [[ "$input" ]]; then
    # …
fi

Part 4: The Response

Now that we know the user has inputted something, we can respond!

echo -n "Mo"
seq 1 $(($RANDOM % 15 + 1)) | while read n; do
    if [ "$(($RANDOM % 2))" = "0" ]; then
        echo -n "o"
    else
        echo -n "O"
    fi
done
echo "…"

Let's start with the beginning and ending echo statements.

echo -n "Mo"
# …
echo "…"

Here, we start the line with "Mo" and end it with "…". Between these two segments, we'll be outputting a random number of "o"s.

seq 1 $(($RANDOM % 15 + 1)) | while read n; do
    # …
done

Above, we see one of my favorite tricks: piping a command's output to a while loop. That lets us execute an action for each line; in this case the line will be stored in the n variable. Now, what's going on with the command we're passing to the loop?

seq 1 … - the seq command outputs all the numbers between and including the two we specify. We start at 1 and continue to the result of the tricky bit of this line, which will essentially spit out a random number between 1 and 15. By piping this to while, we'll be executing the contents of while a random number of times between 1 and 15.
$((…)) - the double parentheses let us evaluate a mathematical expression as our argument. For example, $((5 + 3)) would put 8 in its place.
$RANDOM % 15 + 1 - $RANDOM is a special variable that'll return a random number. % is an operator that returns the remainder of the first number when divided by the second. This'll in effect get us a random integer from 0 to 14; we then add 1 to get a random number from 1 to 15 (which doesn't matter in this case, but I wanted to illustrate the principle).

And, finally, we get to output the "o"s. We're inside the loop, now, which means whatever commands we put will be executed from 1 to 15 times. We could simply just do this:

echo -n "o"

But, to have a little more fun, let's randomly use either an o or an O to add more character to our moos.

if [ "$(($RANDOM % 2))" = "0" ]; then
    echo -n "o"
else
    echo -n "O"
fi

Most of this is pretty straightforward. If $(($RANDOM % 2)) is 0, output an "o", if not, a "O".

Now, what is $(($RANDOM % 2))? Well, let's think back to our last use of $RANDOM. $RANDOM % 2 represents the remainder of some random integer divided by two. The only possible outputs are 0 (it divides evenly by 2) and 1 (it's an odd number, with one remainder), effectively running the first command half the time and the second command for the other half.

Wow, that's everything.

Putting it All Together

Let's take another look at the completed script, shall we?

#!/usr/bin/env bash

while true; do
	printf "$ "
	read input
	if [[ "$input" ]]; then
		echo -n "Mo"
		seq 1 $(($RANDOM % 15 + 1)) | while read n; do
			if [ "$(($RANDOM % 2))" = "0" ]; then
				echo -n "o"
			else
				echo -n "O"
			fi
		done
		echo "…"
	fi
done

In this script we:

Establish the interpreter as bash, using /usr/bin/env to find the path to bash
Enter an infinite loop
Take user input, with $ as a prompt
Output a random number of "o"s—half capital and half lowercase—between Mo and …

Let's try it! Put the code into a file (I use one named moosh), and run it:

$ ls
moosh
$ ./moosh
bash: ./moosh: Permission denied

Uh oh, what happened?

The answer is simple: we haven't told your OS that ./moosh is a file you can execute. Now, you could work around this by passing the file to bash directly (bash ./moosh), but there's a better way.

$ chmod +x ./moosh

This gives us permission to execute the file.

benjamin@tty1.blog ~] $ ./moosh
$ █

Hooray! moosh has launched! Let's try some commands:

$ ping tty1.blog
MooooooooOOoOooOo…
$ echo "This is the Moo Shell"
MooOOO…
$ cat ./moosh
MoOoOooOoO…

It works! Give yourself a pat on the back. 🎉

Conclusion

I hope that, as silly as this project was, walking through it step by step helped you get a picture of how bash scripting works. I'll likely point to this as an example in the future so that I can go in a little less detail if we walk our way through scripts again.

I had fun, I hope you did too. I'm always learning myself and am open to feedback on moosh and how I could have made it better or feedback on my explanation in this article; if you have comments or concerns, I'd be gratified if you'd leave a reply down below.

$ say-goodbye
MoooOoooOoO…

Shell, Yes!

2023-07-14T13:29:18.000Z

For any Linux enthusiast, administrator, developer, systems engineer, or overall neck-beard, the terminal is the meat and potatoes of a good chunk of day-to-day work and interaction with Linux. Your terminal's shell is a powerful tool to make your work easier and more fun to work with.

Configuring your shell to work for your needs is a useful skill to have and is at the heart of automation in your terminal environment. We computer nerds are lazy and love tweaking computer environments to do work for us.

Anatomy

I'm going to break down shell configurations into several different files (more details in this awesome Unix StackExchange answer):

rc - controls our shell's interactive behavior.
env - contains exported environment variables.
aliases - contains—you guessed it—our aliases.

There are a few other files, but I'll mention them later.

The `rc` file

An rc file (or a RUNCOM file) is a file or directory designated to hold configurations for an interactive shell. Modern shells usually come preinstalled with an rc file with several example configuration lines and inline comments explaining them, and these example files can vary between Linux distributions.

This is the best place to start your configurations, and there are plenty of experienced users out there who run their shell with all of its configurations in this file alone. The rc is arguably the most important config file for your shell. (The second most important is the file that makes it look cool.)

Let's start configuring this thing. We'll continue using zsh as our example here, and will pull the important lines from the generated zshrc that comes with a zsh install, as well as add a few of our own.

# .zshrc

HIST_STAMPS="mm/dd/yyyy"
ENABLE_CORRECTION="false"

if [ -f ~/.aliases ]; then
    . ~/.aliases
fi

eval "$(dircolors -p | \
    sed 's/ 4[0-9];/ 01;/; s/;4[0-9];/;01;/g; s/;4[0-9] /;01 /' | \
    dircolors /dev/stdin)"

function precmd {
    if ! typeset -f deactivate >/dev/null; then
        for activate in ./venv/bin/activate ./.venv/bin/activate; do
            if [ -e "$activate" ]; then
                . "$activate"
            fi
        done
    fi
}

if ! [[ -n $SSH_CONNECTION ]]; then
  if [ "$TMUX" = "" ]; then tmux; fi
fi

We'll break this down line-by-line:

HIST_STAMPS="mm/dd/yyyy" describes the timestamp formatting for our shell history.
ENABLE_CORRECTION="false" sets command-line autocorrection.
The if block checks for our .aliases config file, and makes sure zsh sees it.
The eval statement removes the background colors of directories when running ls commands.
The function precmd will activate a venv when navigating to a directory that holds a venv.
Lastly, the if block at the bottom will activate tmux when the shell is launched, as long as it's not over a ssh connection.

The `env` file

The env (environment) file contains our exported variables, we want to put variables that other programs will see or use in here. Some examples (from the previous StackExchange answer) include your $PATH, $EDITOR and $PAGER environment variables. The zsh .zshenv file is always sourced.

Here are some lines from my .zshenv file:

# .zshenv

export DOTFILES=$HOME/.dotfiles
export DOCKER=podman
export PATH=$HOME/bin:/usr/local/bin:$PATH
export LANG=en_US.UTF-8

# Preferred editor for local and remote sessions
if [[ -n $SSH_CONNECTION ]]; then
  export EDITOR='vim'
else
  export EDITOR='hx'
fi

First, we create a DOTFILES variable that describes the location of our dotfiles (I'll go over this later, but this is where we'll store our configs for backups and version control).

Next, I prefer to use Podman over Docker, so for convenience, I have the $DOCKER env variable point to podman instead.

Then, a line that adds $HOME/bin and /usr/local/bin to $PATH, then we set $LANG to en_US.UTF-8.

In the if block here at the end, we set $EDITOR to Helix if we're not on a ssh connection, and Vim if we are connected via ssh.

Now we'll take a look at the contents of the .aliases file we dropped into our .zshrc earlier.

The `aliases` file

This one will be brief, as everyone's aliases are very different from everyone else's. Most of my aliases are ssh commands to quickly jump to other hosts, but there's a few others that I use as well.

# .aliases

# grep
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'

# cat
alias cat='bat --theme Nord -p'

# ls 
alias ll='ls -Al'
alias la='ls -A'
alias ls='ls --color=auto'
alias l='ls -CF'

# dir
alias dir='dir --color=auto'
alias vdir='vdir --color=auto'

# opening files in your $EDITOR
alias ali='$EDITOR ~/.aliases'
alias zrc='$EDITOR ~/.zshrc'

# source config files
alias arc='source ~/.aliases'
alias src='source ~/.zshrc'

# system updates (this is for rpm-based systems like Fedora)
alias upd='sudo dnf upgrade -y && flatpak update'

These are pretty straight forward. We use the alias keyword followed by a key-value pair describing our alias and the command it represents. The ls, grep, and dir aliases here can be copied and pasted without issue; the cat alias will require bat, a fancy cat alternative. The rest are shortcuts to open or source config files in the set $EDITOR (from the env file), plus one to run system updates on Fedora.

Zsh will read these as though they were directly in the .zshrc. I like to keep the aliases separate, it feels more organized to me, but there's no issue at all with dropping them straight into the rc if you like everything in one place. They will both work the same.

These examples work independently from one another; when you come across examples like these, try experimenting with them line-by-line, and work them into your own configuration, instead of dropping them all blindly in your config.

How Your Shell Loads Its Configs

If you want to segment out your config options, aliases, environment variables, functions, etc. into these separate files, then you should understand the order in which your shell loads them, to avoid any conflicts and redundancies.

These config files are really just scripts, like any other shell script, that are called when the shell is run or exited.

Here's how zsh will load its config files, from this great post:

+----------------+-----------+-----------+------+
|                |Interactive|Interactive|Script|
|                |login      |non-login  |      |
+----------------+-----------+-----------+------+
|/etc/zshenv     |    A      |    A      |  A   |
+----------------+-----------+-----------+------+
|~/.zshenv       |    B      |    B      |  B   |
+----------------+-----------+-----------+------+
|/etc/zprofile   |    C      |           |      |
+----------------+-----------+-----------+------+
|~/.zprofile     |    D      |           |      |
+----------------+-----------+-----------+------+
|/etc/zshrc      |    E      |    C      |      |
+----------------+-----------+-----------+------+
|~/.zshrc        |    F      |    D      |      |
+----------------+-----------+-----------+------+
|/etc/zlogin     |    G      |           |      |
+----------------+-----------+-----------+------+
|~/.zlogin       |    H      |           |      |
+----------------+-----------+-----------+------+
|                |           |           |      |
+----------------+-----------+-----------+------+
|                |           |           |      |
+----------------+-----------+-----------+------+
|~/.zlogout      |    I      |           |      |
+----------------+-----------+-----------+------+
|/etc/zlogout    |    J      |           |      |
+----------------+-----------+-----------+------+

If you use bash, here's a table describing the equivalent files and their load order in bash from the same post.

Show table

+----------------+-----------+-----------+------+
|                |Interactive|Interactive|Script|
|                |login      |non-login  |      |
+----------------+-----------+-----------+------+
|/etc/profile    |   A       |           |      |
+----------------+-----------+-----------+------+
|/etc/bash.bashrc|           |    A      |      |
+----------------+-----------+-----------+------+
|~/.bashrc       |           |    B      |      |
+----------------+-----------+-----------+------+
|~/.bash_profile |   B1      |           |      |
+----------------+-----------+-----------+------+
|~/.bash_login   |   B2      |           |      |
+----------------+-----------+-----------+------+
|~/.profile      |   B3      |           |      |
+----------------+-----------+-----------+------+
|BASH_ENV        |           |           |  A   |
+----------------+-----------+-----------+------+
|                |           |           |      |
+----------------+-----------+-----------+------+
|                |           |           |      |
+----------------+-----------+-----------+------+
|~/.bash_logout  |    C      |           |      |
+----------------+-----------+-----------+------+

Assuming you've launched an interactive zsh login, the shell will check for config files in /etc first, load the contents from those files, then check your home directory.

The zshenv file is loaded first, then your zprofile (Here, we want to place our configs for login shells. This is an alternative to the login file (or .zlogin), which is sourced after the rc). Next is our zshrc, and finally, the zlogin. The zlogout file is executed when you exit the interactive shell.

Notice that on an interactive non-login instance, our zshenv and zshrc files are the only files that are sourced, and the zshenv file is the only file sourced from scripts.

Bonus: Managing Your Dotfiles with GNU Stow

So you've got all these files now, but how do you organize and manage them? If you've consolidated everything to just the .zshrc, then there are no issues with just dropping it in your home directory and leaving it at that, but if you expect your configs to grow and want a way to organize them, keep backups, and use some version control then you can place them all in a git repository and use a symbolic link manager like GNU Stow.

We'll start by taking a look at stow and building out a directory structure that it can use to manage our dotfiles. Create a directory in your $HOME called .dotfiles and create a zsh subdirectory inside it, then move (mv, not cp) the dotfiles we've worked on to that directory, like so:

$ tree -a ~/.dotfiles 
/home/btp/.dotfiles/
└── zsh
    ├── .aliases
    ├── .zshenv
    └── .zshrc

1 directory, 3 files

This .dotfiles directory will be our root directory when using stow, and inside this directory we'll be storing our stow "packages", which we'll be calling stow on to install.

In this example, we'll be creating a zsh package which will install the three config files we've created to the target directory we give to stow.

By default, the target directory is the directory above the stow root directory, which is our home directory in this case. If you want to change the target directory, add the -T /path/to/target flag and argument.

First, let's install this zsh package with stow. Run the following command in your .dotfiles directory.

~/.dotfiles] $ stow --stow zsh

This will call stow on our zsh package, and install our dotfiles in the directory above our .dotfiles directory, which is $HOME. The --stow flag can also be -S. Stow uses symbolic links, and "installs" by creating the symbolic link in the target directory.

This is the same as if you would run ln -s /home/user/.dotfiles/zsh/.zshrc /home/user/ for each of these files.

Now consider the following stow packages:

$ tree -a ~/.dotfiles
/home/btp/.dotfiles
├── alacritty
│   └── .config
│       └── alacritty
│           └── alacritty.toml
└── zsh
    ├── .aliases
    ├── .zshenv
    └── .zshrc

4 directories, 4 files

In this case, we've added a config package for the terminal Alacritty. Stow will check the full path under the package, and mirror it to our target location. When running the stow command on this package, it will add the full config path ~/.config/alacritty/alacritty.toml, which is exactly where we want it.

You can layer your Stow root directory however you want, but when you install packages, you'll need to navigate to the directory that holds the package itself; Stow will not accept a path to a package:

# this will NOT work.
~] $ stow -S .dotfiles/zsh

I keep my .dotfiles in a git repository and hold configs for multiple operating systems there, then navigate to the relevant OS directory for installs, like so.

tree ~/.dotfiles/
└── dots
    ├── linux
    │   ├── alacritty
    │   ├── awesome
    │   ├── helix
    │   ├── nushell
    │   ├── nvim
    │   ├── p10k
    │   ├── powershell
    │   ├── starship
    │   ├── tmux
    │   └── zsh
    ├── macos
    │   ├── alacritty
    │   ├── helix
    │   ├── nushell
    │   ├── nvim
    │   ├── p10k
    │   ├── powershell
    │   ├── starship
    │   ├── tmux
    │   └── zsh
    └── wsl
        ├── helix
        ├── nushell
        ├── p10k
        ├── powershell
        ├── starship
        ├── tmux
        └── zsh

Conclusion

I tried to limit the scope of this article to avoid confusion, and also to avoid a massive post. This topic is very subjective, so take these examples as just that, examples. I've found what works for me when building and managing my config files in a scaleable way, and I hope this has helped you as well. Enjoy!

Terminal-Based Music

2023-06-10T14:06:55.000Z

About a year ago, I stopped using Spotify for my music, instead moving to local audio files. I've never regretted that decision. When I started transitioning to a terminal-based workflow, though, I had to find good utilities to manage and play my collection.

I think that the results have been far more useful than the graphical apps I used to use were.

Acquiring Music

My preferred method of acquiring music is to buy used CDs and rip them. My tastes in music are fairly old, mostly classical, big band, etc., so I can get away with this. I go to Half Price Books and buy up a bunch of clearanced CDs for 50¢ each.

You may decide to pursue a "less legal" solution, but I won't comment on that, except to point out a helpful alias I have set up for yt-dlp, to download audio from YouTube:

alias yt-audio='yt-dlp -x --audio-format mp3'

Then I can simply run yt-audio [link to song or playlist] to download a song or album to the current directory.

On to what I do with my CDs. I've settled on abcde. Once again, I've set up an alias to automatically apply settings I want.

alias rip='abcde -Vx -o flac'

-V - Makes the output more verbose, making sure I get all status updates. I like verbose output. :)
-x - Ejects the disk once abcde is finished.
-o flac - Outputs the files in the flac format

I cd ~/downloads, run rip, and abcde creates a subfolder with all the files, trying to see if it can find information on the album and adding metadata if it does.

Managing the Library

The magic of my music management happens through beets, which bills itself as "the music geek's media organizer". If you're interested in my configuration, I have it posted in my dotfiles. Basically, it sets where I store my music, says to move music files rather than just copying them, and gets album art when importing.

Once I've ripped a bunch of CDs into ~/downloads with abcde, I run beet im . in ~/downloads to import all the albums. It automatically looks for album metadata from MusicBrainz, adds it to the files, then sorts them into your music collection. Mine is set up to be at ~/music.

If you want to learn all of beets's features, it has online documentation available. There are also manpages: man beet for the CLI and man beetsconfig for information on configuring beets.

Playing Music

I play music through cmus. It's pretty self-explanatory; if you don't understand something, see man cmus. You'll probably want to take a look there at first to find all the default keybindings.

One thing you will have to do is add music from your collection. Go to the "Browser" view with 6, use arrows or j and k to highlight the directory you store your music in, then use a to add everything in it to your Library (at which point it will be viewable in the default view; you can get back there with 1). You'll want to do this again whenever you add get new music.

Getting Metadata

I sometimes want to see what's playing without going over to cmus. In SwayWM, my window manager, I can set it to run commands or scripts when a keyboard shortcut is triggered.

I use playerctl to get information about what's currently playing, which has worked for most music players I've tried. Here's my custom notify-playing script:

#! /bin/sh
metadata=$(playerctl metadata)
title=$(echo "$metadata" | grep ":title\b" | awk 'BEGIN{FS=" {2,}"}{ print $3 }')
artist=$(echo "$metadata" | grep ":artist\b" | awk 'BEGIN{FS=" {2,}"}{ print $3 }')
album=$(echo "$metadata" | grep ":album\b" | awk 'BEGIN{FS=" {2,}"}{ print $3 }')
artUrl=$(echo "$metadata" | grep ":artUrl\b" | awk 'BEGIN{FS=" {2,}"}{ print $3 }')

notify-send "$title" "$artist – $album" -i "$artUrl" -t 5000 || notify-send "Nothing playing." -t 5000

Put it in a folder in your $PATH. Now, when notify-playing is run, you get a notification with the title, album, and artist of the song playing.

Bonus: Streaming Music

While it's not strictly for the terminal, I use gonic to stream music to my phone from my collection, since the collection is too large to store full-quality copies on my phone. I won't go into all the details, but it's a streaming backend that works well with beets, so I thought I'd mention it.

Conclusion

This whole workflow won't be perfect for everyone. Still, parts of it can be integrated into whatever your ideal music setup is. Specifically, I think beets is a tool can fit into and improve any setup.

Crafting your music setup is a journey, and it's different for everyone. Once you've figured out the specifics of your setup, do let me know! I'm happy to compare notes and perhaps learn some tips myself.

Happy listening!

Leveling Up Your Filetree with xdg-user-dirs

2023-05-08T02:21:59.000Z

Have you ever noticed that there are certain directories everyone has? ~/Documents, ~/Downloads, ~/Desktop, and so forth? Some of them you don't need, some of them you might wish were named differently, but any time you rename or delete them, the originals reappear?

You see, these directories follow a standard so that all programs know where they are—with the right tools under your belt, you can customize them.

Meet `xdg-user-dirs`

xdg-user-dirs is a set of two utilities that manages the placement of standard directories on your installation. Most people already have it, though they may not know about it, since it comes with many major Desktop Environments.

If you don't have it, go ahead and install it now.

To get started, run this command:

$ xdg-user-dirs-update

This command creates all of the configured folders on your system. If it's not already configured, it will create the configuration file for you.

By default, these are the folders it creates:

~/Desktop
~/Documents
~/Downloads
~/Music
~/Pictures
~/Public
~/Templates
~/Videos

Now that everything's set up, let's customize these folders to our taste.

Customizing Your User Directories

There are two configuration files to worry about. If you want to configure the default folders for every user on your installation, you can edit /etc/xdg/user-dirs.defaults. To configure user-specific folders, edit ~/.config/user-dirs.dirs.

By default, you get this:

# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you're
# interested in. All local changes will be retained on the next run.
# Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
# absolute path. No other format is supported.
# 
XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_TEMPLATES_DIR="$HOME/Templates"
XDG_PUBLICSHARE_DIR="$HOME/Public"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_MUSIC_DIR="$HOME/Music"
XDG_PICTURES_DIR="$HOME/Pictures"
XDG_VIDEOS_DIR="$HOME/Videos"

In itself, this is pretty self-explanatory. Let's do some simple customization and make all of these directory names lowercase, for easier typing in the terminal.

XDG_DESKTOP_DIR="$HOME/desktop"
XDG_DOWNLOAD_DIR="$HOME/downloads"
XDG_TEMPLATES_DIR="$HOME/templates"
XDG_PUBLICSHARE_DIR="$HOME/public"
XDG_DOCUMENTS_DIR="$HOME/documents"
XDG_MUSIC_DIR="$HOME/music"
XDG_PICTURES_DIR="$HOME/pictures"
XDG_VIDEOS_DIR="$HOME/videos"

Now, you could go ahead and lock this in, but this would only create new directories in the new locations; it doesn't move the current folders. Let's do that first, so that we don't have a bunch of extra directories.

mv ~/Desktop ~/desktop
mv ~/Downloads ~/downloads
mv ~/Templates ~/templates
mv ~/Public ~/public
mv ~/Documents ~/documents
mv ~/Music ~/music
mv ~/Pictures ~/pictures
mv ~/Videos ~/videos

Now that our files are in the right place, let's update our user directory listings:

$ xdg-user-dirs-update

Now, any compatible program will automatically use the new directories you've specified. Hooray!

Removing Default Directories

Sometimes you don't want one of the directories that xdg-user-dirs adds by default. I, for example, don't have any need for ~/desktop. Well, let's try removing it:

XDG_DOWNLOAD_DIR="$HOME/downloads"
XDG_TEMPLATES_DIR="$HOME/templates"
XDG_PUBLICSHARE_DIR="$HOME/public"
XDG_DOCUMENTS_DIR="$HOME/documents"
XDG_MUSIC_DIR="$HOME/music"
XDG_PICTURES_DIR="$HOME/pictures"
XDG_VIDEOS_DIR="$HOME/videos"

$ rmdir ~/desktop
$ xdg-user-dirs-update
$ ls
Desktop documents download music pictures public templates videos

Oops, it reappeared, in the default form. If we check back in our config file, we'll find this added to the end:

XDG_DESKTOP_DIR="$HOME/Desktop"

Okay, so xdg-user-dirs won't let us remove the default directories. Why? Because there are programs that rely on those folders existing, and xdg-user-dirs doesn't want them to be missing when those programs go looking.

So, is there a workaround? Well, let's think about this use-case. What do programs usually want to know about the desktop for? Usually so they can put a file or link there for quick access. For me, that's what the downloads folder tends to be for. Let's try something:

XDG_DESKTOP_DIR="$HOME/downloads"

…and it works, even though XDG_DOWNLOAD_DIR is already set to $HOME/downloads. You can double up like this, which I find handy.

You can also set one to a subdirectory:

XDG_TEMPLATES_DIR="$HOME/documents/templates"

Adding Extra User Directories

Perhaps you want an extra directory defined, besides what the defaults are. I, for example, have extra user directories for my writing, screenshots, and notes:

XDG_WRITING_DIR="$HOME/writing"
XDG_SCREENSHOTS_DIR="$HOME/pictures/screenshots"
XDG_NOTES_DIR="$HOME/notes"

While these aren't used by any programs I use, I can reference them in my own scripts. For example, if I have multiple scripts that need to access my notes, I no longer have to update each one if I decide to move my notes; all I need to do is update XDG_NOTES_DIR and run xdg-user-dirs-update.

How do you reference these directories? Let's learn.

Using `xdg-user-dir`

To get the location of a user directory, use the xdg-user-dir command:

$ xdg-user-dir NOTES
/home/benjamin/notes

Want to include this as part of a command? Say, for example, that you have this in a script:

echo "You have $(ls ~/notes/school | wc -l) notes from class"

Notice the $(); anything inside the parentheses is replaced with its output when run as a command. So, let's use this to update the script:

echo "You have $(ls "$(xdg-user-dir NOTES)/school" | wc -l) notes from class"

Et voila! Now, whenever you move your notes and update the user-dir configuration, any scripts using this strategy will automatically work with the new location.

Closing Thoughts

You don't have to mess around with your user directories. Much of what I've talked about here may not be interesting to you.

But having the knowledge of what goes on behind the scenes? That's valuable. And who knows, perhaps you'll find a time when this comes in handy. To me, it's helped give a more personal touch to my file organization, letting me do things my way rather than the way they came by default.

Go forth and be awesome.

In case it helps anyone, here's how my directories are configured, as of this writing:

XDG_DOWNLOAD_DIR="$HOME/downloads"
XDG_LINKS_DIR="$HOME/links"
XDG_DOCUMENTS_DIR="$HOME/documents"
XDG_WRITING_DIR="$HOME/writing"
XDG_MUSIC_DIR="$HOME/music"
XDG_PODCAST_DIR="$HOME/podcasts"
XDG_PICTURES_DIR="$HOME/pictures"
XDG_SCREENSHOTS_DIR="$HOME/pictures/screenshots"
XDG_VIDEOS_DIR="$HOME/videos"
XDG_TEMPLATES_DIR="$HOME/templates"
XDG_PUBLICSHARE_DIR="$HOME/public"
XDG_SCHOOL_DIR="$HOME/school"
XDG_NOTES_DIR="$HOME/notes"
XDG_DESKTOP_DIR="$HOME/downloads"

Also, do you remember my templates trick from the last article? That's a good use of XDG_TEMPLATES_DIR.

You Don't Need a File Manager

2023-04-08T20:17:32.000Z

A file manager feels like an essential part of an operating system. In a blog where I talk largely about using terminal applications instead of GUIs, you might think I'd spend this article exploring some terminal-based file managers.

Not so. Spare me a moment of your time, friend, and I will endeavour to illuminate why you, master of command-line secrets, have no need for such a petty thing as a "file manager."

Replacing Functionality

Let's walk through the different things traditional file managers do and figure out new ways to do them with regular terminal commands.

Listing Files

If you know anything about the terminal, you should know this command. (If you don't, I pick it to pieces here.)

$ ls

Creating Files

If you want to create an empty text file, you can do this easily with touch:

$ touch ~/notes/things-to-do-today.md

To create a directory, use mkdir:

$ mkdir ~/notes/top-secret

If ~/notes doesn't already exist, this will throw an error. To create all necessary folders (and not just the final one), use the --parents/-p flag.

$ mkdir --parents ~/notes/top-secret

$ mkdir -p ~/notes/top-secret

If you're wanting to create files from templates, that's also pretty easy. First, create a folder to store your templates in.

$ mkdir ~/templates

Whenever you have a new type of file you want to make a template for, create a file that's a starting point for the type in this templates folder. Then, when you want to create a new file with that template, do it like so:

$ cp ~/templates/tty1-post.md ./no-file-manager.md

Opening Files

This one seems a bit tricky, but it's easy once you have it figured out. If you want to open a file in the default program, use xdg-open, from xdg-utils.

$ xdg-open <file>

Setting the default program for a file type is a bit trickier. xdg-mime is the standard way to do so (see man xdg-mime), but I prefer to use a utility called mimeopen.

$ mimeopen <filename>

If you already have a program set to open the file in, it'll just open it. If not, it'll ask you to pick the program. If you want to force it to ask you even though you've set the default application, use the --ask-default/-d flag:

$ mimeopen --ask-default <filename>

I set an alias for this to make it even easier:

alias open="mimeopen"

Now running open <file> will open <file> with the default program, asking which to use if you haven't set it.

Moving Files

Moving files and directories is pretty easy.

$ mv ~/downloads/download.pdf ~/documents

This will move download.pdf from ~/downloads to ~documents.

Renaming Files

This solution is actually the same. You can use mv to rename files and folders.

$ mv untitled.md world-domination-plan.md

You can even move and rename at the same time:

$ mv ~/downloads/untitled.md ~/notes/top-secret/world-domination-plan.md

However, you'll often want to rename multiple files in the same directory. There are a lot of tools for that, but I've settled on edir, myself.

~/folder]$ edir

This will open a list of the files in the directory in my default text editor:

1	./untitled
2	./untitled (1)
3	./untitled (1) (1)
4	./untitled (1) (1) (1)
5	./untitled (1) (1) (1) (1)
6	./untitled (1) (1) (1) (1) (1)
7	./untitled (1) (1) (1) (1) (1) (1)

Not very pretty, huh? Now that it's in my text editor, though, I can edit the names of any of those files here.

1	./cool-file
2	./secret-plans
3	./birthday-present-ideas
4	./cookie-recipe
5	./ultimate-brownies
6	./short-story
7	./public-speaking-notes-03-31-2022

When I save and exit, edir will apply the changes for me!

~/folder]$ edir
Renamed untitled to cool-file
Renamed untitled (1) to secret-plans
Renamed untitled (1) (1) to birthday-present-ideas
Renamed untitled (1) (1) (1) to cookie-recipe
Renamed untitled (1) (1) (1) (1) to ultimate-brownies
Renamed untitled (1) (1) (1) (1) (1) to short-story
Renamed untitled (1) (1) (1) (1) (1) (1) to public-speaking-notes-03-31-2022
~/folder]$ ls
birthday-present-ideas  cookie-recipe  cool-file  public-speaking-notes-03-31-2022  secret-plans  short-story  ultimate-brownies

How helpful this is will depend partly on what text editor you use. For me, in neovim, editing filenames this way is far easier than repeatedly using mv.

edir may be packaged in your distribution, but if not it's available through pipx:

$ pipx install edir

For more information see its repository.

Deleting Files

Deleting files is easy.

$ rm ~/unwanted-file.pdf

Or delete all the files in a folder.

$ rm ~/downloads/*

Deleting a directory is a little trickier. rmdir will do the trick if it's empty.

$ rmdir ~/junk-folder/

You can also use the --parents/-p flag, like in mkdir. However, if you want to remove a directory and everything in it, you'll need rm again, this time with the --recursive/-r flag.

$ rm --recursive ~/junk-folder/

Now, rm permanently deletes files. While this can be what you want, this isn't what a file manager usually does; it would move deleted files to the "trash." Well, so can you, with trash-cli, a suite of commands to help you manage your trash!

I'm going to give some quick examples below, but for full instructions use the manpages for the commands.

Trash files or folders

trash <path>

Empty trash older than `days`

trash-empty [days]

You'll want to do this fairly regularly or you won't be saving any storage space. I personally run trash-empty 7 once every couple days.

Restore trashed files

trash-restore

This will walk you through the process.

Advanced: Mounting Drives

Now, I could go into the mount command and how to use it, but if you want something that complex and nuanced, you can read man mount yourself. I already went into a complicated command in-depth recently and I don't feel like doing it again here. (The mount manpage is 80% longer than the tar manpage.)

Instead, I'd like to point you to udisks2. It provides the handy udisksctl utility.

Once you have udisks2, though, you have an even easier simpler solution: udiskie. Install it, set it running, and any drives you attach will automatically be mounted to your filesystem. The result will be put in a folder depending on your distro; I've seen /media/<your-username> and /run/media/<your-username> as the base directory.

Your desktop environment might already be set up to automatically mount drives, in which case you can ignore this section. If you're using a barebones window manager like me, though, this could come in handy.

Honorable Mentions: Terminal-Based File Managers

Despite all this, there are some great terminal file managers out there. Here are some I've heard of, in no particular order.

vifm
ranger
nnn (I have actually tried this one)
lf

I don't use any of these, so I don't make any guarantees of quality, but I have heard good things from people who do. Consider giving them a shot, but at least try to go terminal-only first; you have what it takes!

Conclusion

Surely by this point you have been convinced. You, discriminating command-line magician that you are, have no need for the crutch that a file manager is.

Unleash your inner terminal nerd and manage your files with your terminal only! (At the very least, you'll get some sweet, sweet, nerd cred.) Go forth and be awesome.

How to Save the World with tar

2023-03-31T23:13:41.000Z

While there are hundreds of difficult-to-understand commands out there, few have acquired the notoriety of tar. Most guides are filled with abstruse commands such as tar -czvf archive.tar.gz ~/Downloads/ with little to no explanation. Based on conversations I've had, people who interact with tar tend to just memorize a basic command or two, like tar -xvf <filename> and hope for the best.

xkcd#1168 by Randall Munroe

Let's take a closer look at tar and learn how it actually works.

A Quick Summary

tar is used for creating and interacting with archive files; .tar archive are similar in functionality to .zip files, which you may be more familiar with.

The name "tar" is short for "tape archives"; the original idea behind tar is that the archives in question would be stored on tape. In contemporary usage, that's not usually the case.

The "Easy" Way to Learn

The best explanation of tar is in its manual page.

$ man tar

However, this man page is extremely long and most people skip it altogether. Still, if you want a deeper understanding than what this guide will give you, the man page is the place to go.

Usage Styles

"Traditional" Usage

$ tar xvf archive.tar.gz

I won't cover this style in this article. Most of the basics are similar to Unix-style flags, and any other information you need to know is explained within man tar under Description ⇒ Option Styles. It's not the style I recommend you use, but it may be handy to understand if you see it in another guide.

"Unix-style" Usage

$ tar -xvf archive.tar.gz

These are standard short flags; you can use them individually (-x -v -f) or combine them (-xvf). This is the form you'll usually see used.

"GNU-style" Usage

$ tar --extract --verbose --file=archive.tar.gz

I think this is the most straightforward way to use tar; it's much clearer what the different flags mean and which arguments are passed to which flags. However, it's much harder to type out, so it isn't usually used.

Something many people don't know, though, is that you don't have to type out the full flags; you can just use the first letters, as long as the letters you type are unique to one flag.

$ tar --ext --verbo --file=archive.tar.gz

If you shorten a flag too far and there are multiple possibilities, tar will warn you and give you the possible completions.

Flag Walkthrough

Let's go through some of the most useful flags one by one and learn how they're used.

`--verbose`/`-v`

The --verbose flag just makes sure that you'll see all output from the command you run; by default, most tar commands will just do everything without returning any output, making it hard to tell if anything is happening, especially when a command takes a long time to run.

As a general rule, I add --verbose to almost every tar command I run; I like seeing what's going on. It will, though, spit out a ton of information, filling up your terminal screen, which might not be what you want.

`--extract`/`-x`

This flag says to extract the contents of an archive; you'll need to use the --file flag for it to do anything, which we'll learn about next.

Optionally, it takes arguments to specify which files to extract.

`--file`/`-f`

This flag specifies the archive file that you'll be working with, whether you're creating it, reading from it, adding files, etc. It takes one argument, the location of the archive file.

This is a good time to talk about how to pass arguments in tar. The long flags are the easiest to pass to:

$ tar --extract --file=archive.tar.gz

You can use a space instead of the =, but I suggest you use = for clarity.

For short flags, the argument value must follow the flag it's being passed to. This can take multiple forms:

$ tar -f archive.tar.gz -xv

$ tar -xvf archive.tar.gz

`--list`/`-t`

This flag says to list everything in an archive specified by --file or -f.

$ tar --list --file=archive.tar.gz

$ tar -tf archive.tar.gz

I don't generally bother including -v with this, since it'll be outputting the contents of the archive anyway.

Optionally, this takes arguments to specify which files to list.

`--create`/`-c`

This flag says to create a new tar archive with the filename and location specified by -f or --file. It takes one or multiple arguments to specify which files to add to the new archive.

$ tar --create=~/school --file=school.tar --verbose

$ tar --create ~/school ~/Downloads ~/writing --file=archive.tar --verbose

$ tar -cvf archive.tar ~/projects

Note that arguments passed to the action flag (such as -c, -t, -x) can be put at the end of the command, after all the other flags, as shown in the last example above. I couldn't find any specific rationale for that in the tar manpage, but it works and people often do it that way.

`--gzip`/`-z`

--create alone doesn't apply any compression to files; to do that, you need to select a compression method. I personally always use gzip, which is applied with the --gzip or -z flag.

$ tar -czvf archive.tar.gz ~/Downloads

To use a different compression type, swap out this flag for the flag of the type you want to use. By convention, an extra file extension is appended to compressed archives, depending on the type of compression.

--gzip/-z - gzip compression, uses .tar.gz
--bzip2/-j - bzip2 compression, uses .tar.bz2
--xz/-J - xz compression, uses .tar.xz

There are some others too, but you get the idea. See man tar for a full list of compression methods.

There's another way to do compression that you might find easier; use --auto-compress/-a to automatically detect how to compress the file based on the filename you chose. For example:

$ tar -cavf archive.tar.xz ~/Downloads

This will notice the .tar.xz ending to the archive name and automatically use xz compression.

`--append`/`-r`

This will add files to an archive. Use it the same way you would --create/-c; use --file/-f to specify the archive, then pass directory and file paths to it to have them added to the archive.

$ tar -rvf school.tar.gz ~/Downloads/syllabus.pdf

There are many other flags for tar, some of which may be useful to you. The goal of this article was largely to get you to the point where reading the manual page will actually be helpful rather than just daunting. If you need to do something you don't know how to with tar, here's what I'd recommend:

Begin by searching up what you want to do and finding a guide for it. Unfortunately, most guides to tar aren't very conducive to actually understanding what you're doing, just rote memorization.
Take any flags you don't understand from what you find and look for them in man tar to get full instructions for how to use them. The manpage is actually pretty helpful if you're just looking up flags with a basic preexisting knowledge of how tar works.

Practice

Let's try this out; I'll begin by giving you some example commands with tar (using short flags, since the long ones are pretty easy). See if you can figure out what they do, then look at the explanation to test your knowledge.

$ tar -xvf archive.tar.gz

Show Explanation

-x - this is the action; this command will be extracting all contents of an archive (since specific contents were not passed to the argument)
-v - the command will be spitting out extra information as a status report
-f - this gets passed the archive we're working with; in this case, archive.tar.gz is the archive. (Note that it is compressed using gzip.)

The final result? The archive gets decompressed to the current directory. If you're going to remember one tar command, this is a good one; it will always extract the archive you specify, regardless of compression.

$ tar -xvwf archive.tar

Show Hint

You're going to need to test your manpage-searching skills for this one!

Show Explanation

This is almost the same as the last one; the only difference is the added -w flag. If you checked man tar, you know that this flag means that tar will ask for individual confirmation before extracting each file.

$ tar -cavf backup.tar.gz ~/Documents

Show Explanation

-c - creates an archive
-a - automatically detects what compression to use based on the filename of the archive
-v - use verbose output
-f - sets the filename for the archive, backup.tar.gz—note that this will make the archive use gzip compression, due to the -a flag and the file extension .tar.gz
~/Documents - Makes ~/Documents the content of the new archive

Conclusion

Congratulations, you know enough about tar to save the world from nuclear destruction! Go forth and use your newfound knowledge for good, not evil. (Or, you know, if you want to use it for evil, that's up to you, I suppose.)

See you next time; we'll be considering whether file managers are really necessary.

Anatomy of a Command

2023-03-25T19:26:31.000Z

For the most part, this blog will not be dealing with the very basics. I find it safe to assume that most people interested in a blog about the Linux terminal already have some degree of fundamental knowledge about it.

That said, it's a good idea to have a grounding place we can all start off from. Let's take a command and dissect it, looking at its parts and learning what they mean.

Anatomy of a Command

Lets start off with this simple command:

$ ls --almost-all --sort=extension ~/downloads

Whoa, whoa, whoa, what's going on here? So much. If you're not very used to the terminal, this is a perplexing line of gibberish. Let's break it down.

`$` - The Prompt

See the $ at the beginning of the line? That's what's known as the shell "prompt." Prompts come in all different flavors, but there's one thing that remains consistent between most default prompts, by convention:

If it ends in $, any commands are being run by a normal user
If it ends in #, any commands are being run by the root (or administrator) user

Usually, your prompt will be more complex, something more like this:

benjamin@archimedes:~/projects/tty1.blog] $

A quick rundown of what's going on here:

benjamin - my username
archimedes - the "hostname", or name of the computer I'm using
~/projects/tty1.blog - the path to the "working directory", the current folder I'm inside. Commands run will by default be performed in this folder.

Basically, a prompt is meant to give you information to help contextualize commands you run.

For tty1, I will use the following convention:

For most commands, I'll use a simple $ or #.
If it matters what directory I'm in, I'll use path] $ or path] #. For example, ~/projects/tty1.blog] $.

Keep in mind: the prompt is not part of the command you run. If you're copying a command, don't include the starting $ in what you run or you'll get an error.

`ls` - The Command

While the whole line you enter in is often referred to as a command, the actual command itself is just the program being run. In this case, that's ls, a command which lists files and directories in a directory ("directory" is what most people know as a folder).

`~/downloads` - Arguments

An "argument" is a piece of information you give to a command to help it do its job. Each command will take a certain number of arguments; ls takes one, the path.

Giving a command an argument is called "passing" it the argument. By passing ls (which lists the files and directories in a directory) the ~/downloads path, you're telling it to list for you every file and directory inside the ~/downloads directory.

For ls, this argument is optional; if you'd left it out, by default it would assume you want a list of the files in the folder you're currently inside, the "working directory".

Commands will sometimes have multiple arguments, in which case they're separated by spaces.

`--almost-all --sort=extension` - The Flags

Flags specify options or settings to use when running the command. In this case:

--almost-all means to show all files and folders, including ones that would normally be hidden (files and folders starting with . are hidden by default), but excluding . (referring to the directory itself) and .. (referring to the parent directory).
By default, ls will sort the results alphabetically. Using --sort, you can tell it to sort a different way. Some flags, like --sort, allow or require you to pass arguments to them, like you would with commands. Unfortunately, different commands will often have different ways to do this.

Confused yet? There's more. Most programs have multiple versions of each flag. While each command can do this differently, usually flags starting with -- are "long" flags and ones starting with - are short ones which are easier to type out. For example, in the ls command, -A means --almost-all and -X means --sort=extension. With that in mind, we could have written our command this way:

$ ls -A -X ~/downloads

In fact, you can go even shorter. With one-letter short flags, you can combine them like so:

$ ls -AX ~/downloads

That means the same thing as our original command:

$ ls --almost-all --sort=extension ~/downloads

While short flags are far quicker to type out, I'll avoid using them in this blog, since they're confusing and less understandable than long flags if you don't know what's going on.

Options should be listed before the arguments of the command.

Getting Help

You know how commands work! Well, you know the basics. You're almost certainly going to run into problems and issues, especially since I won't usually be sticking to the basics like I do in this article. Here are some resources that can help with that:

man - gives manual pages for commands. man ls, for example, has a full explanation of how to use the ls command, including its flags and arguments. This is the most comprehensive way to learn about commands you aren't familiar with, but can sometimes be intimidating. A good way to get started with it and learn how it works is to run man man and read the result.
- tldr is a man alternative that simplifies the instructions and gives you a few basic examples. See tldr.sh for more information. This is excellent for quick reference, but tends to oversimplify and may not know about every command you want to use. (You'll need to install tldr; it doesn't usually come installed on your system.)
The ArchWiki is an excellent source of information about anything to do with Linux, even if you're not on Arch (btw)
Ask people for help. Other people are your best bet if you're stuck; many of us have gone through the same issues. If you'd like to ask me, I'm active on Mastodon or you can contact me directly.

Introduction

2023-03-24T14:35:57.000Z

Welcome to tty1, a blog about the Linux terminal!

Who are you, and what is this all about?

Easy to answer the first question:

$ whoami
benjamin

I kid. Let me introduce myself for real.

$ cat about-$(whoami).toml
name = "Benjamin Hollon"

website = "benjaminhollon.com"
code = "codeberg.org/benjaminhollon"
mastodon = "@benjaminhollon@fosstodon.org"

occupation = "university student"
major = "Communications (BA)"
university = "Texas A&M"

hobbies = [
	"writing"
	"coding"
	"astronomy"
	"playing trombone"
	"composing music"
	"reading"
]
dream = "developing and supporting Free and Open Source software for the writing industry"
terminal_emulator_of_choice = "foot"

citizenship = "United States of America"
lived = [
	"Afghanistan"
	"India"
	"Malaysia"
	"United States of America"
]

Is this a nerdy way to introduce myself? Yes. If that's not what you're looking for, I'm sorry to burst your bubble, but you're in the wrong place. This is a nerdy blog for nerdy people.

As for what this is about, tty1 is a blog where I'll share tips, tricks, guides, reviews, and anything and everything related to the Linux terminal. If you don't know what that means, again, you're in the wrong place.

Eventually, this blog may feature guest articles by people who know their stuff; we'll be starting off with articles by yours truly as I get into stride and establish the proper tone and feel for this blog.

Why the name `tty1`?

Long story short, a tty is a terminal for your Linux-based operating system that doesn't require a graphical system like X or Wayland.

Originally, I was going to write this blog about my attempt to daily-drive a Linux installation without a graphical system, doing everything from the tty, hence the title. I've since broadened it to be about the Linux terminal in general, but the name still fits.

Housekeeping

Let's get a few things straight before we begin our grand tour of the Linux terminal.

Subscribing for updates

To get updates, you can use a feed reader, subscribing to the link https://tty1.blog/feed/ for the tty1 Atom Feed. You can also open the link to see a preview of the feed. For an explanation of what Atom Feeds are, check out About Feeds.

For a good terminal client to check your RSS feeds, I highly recommend newsboat. That's the client I use. The website has a comprehensive guide and of course you can always run man newsboat to get information on using it.

Contacting Me

There are a few ways to contact me on my site, but if you're not wanting a private conversation (in which case email is best), I'd love if you reach out to me on Mastodon!

I'm happy to take feedback, topic recommendations, questions, cookie recipes, and anything else on your mind.

Why the "Linux" terminal?

Other operating systems may have great terminals, but I use Linux. Some of what I talk about will apply to other operating systems, but I'm not going to make any guarantees; do your own research to make sure.

Thank you!

With all of this out of the way, we'll be kicking this blog off with a deep dive into the anatomy of a command.

tty1

Real World Solutions: Updating Ebooks

The Setup

the solution

breaking it down

the results

conclusion

moosh: the Moo Shell

The Code

Part 1: The Shebang

Part 2: The Infinite Loop

Part 3: Taking Input

Part 4: The Response

Putting it All Together

Conclusion

Shell, Yes!

Anatomy

The rc file

The env file

The aliases file

How Your Shell Loads Its Configs

Bonus: Managing Your Dotfiles with GNU Stow

Conclusion

Terminal-Based Music

Acquiring Music

Managing the Library

Playing Music

Getting Metadata

Bonus: Streaming Music

Conclusion

Leveling Up Your Filetree with xdg-user-dirs

Meet xdg-user-dirs

Customizing Your User Directories

Removing Default Directories

Adding Extra User Directories

Using xdg-user-dir

Closing Thoughts

You Don't Need a File Manager

Replacing Functionality

Listing Files

Creating Files

Opening Files

Moving Files

Renaming Files

Deleting Files

Trash files or folders

Empty trash older than days

Restore trashed files

Advanced: Mounting Drives

Honorable Mentions: Terminal-Based File Managers

Conclusion

How to Save the World with tar

A Quick Summary

The "Easy" Way to Learn

Usage Styles

"Traditional" Usage

"Unix-style" Usage

"GNU-style" Usage

Flag Walkthrough

--verbose/-v

--extract/-x

--file/-f

--list/-t

--create/-c

--gzip/-z

--append/-r

More

Practice

Conclusion

Anatomy of a Command

Anatomy of a Command

$ - The Prompt

ls - The Command

~/downloads - Arguments

--almost-all --sort=extension - The Flags

Getting Help

Introduction

Who are you, and what is this all about?

Why the name tty1?

Housekeeping

The `rc` file

The `env` file

The `aliases` file

Meet `xdg-user-dirs`

Using `xdg-user-dir`

Empty trash older than `days`

`--verbose`/`-v`

`--extract`/`-x`

`--file`/`-f`

`--list`/`-t`

`--create`/`-c`

`--gzip`/`-z`

`--append`/`-r`

`$` - The Prompt

`ls` - The Command

`~/downloads` - Arguments

`--almost-all --sort=extension` - The Flags

Why the name `tty1`?