Archives

Linux Fu: A Warp Speed Prompt

March 20, 2025 by 26 Comments

If you spend a lot of time at the command line, you probably have either a very basic prompt or a complex, information-dense prompt. If you are in the former camp, or you just want to improve your shell prompt, have a look at Starship. It works on the most common shells on most operating systems, so you can use it everywhere you go, within reason. It has the advantage of being fast and you can also customize it all that you want.

What Does It Look Like?

It is hard to explain exactly what the Starship prompt looks like. First, you can customize it almost infinitely, so there’s that. Second, it adapts depending on where you are. So, for example, in a git-controlled directory, you get info about the git status unless you’ve turned that off. If you are in an ssh session, you’ll see different info than if you are logged in locally.

However, here’s a little animation from their site that will give you an idea of what you might expect: Continue reading “Linux Fu: A Warp Speed Prompt” →

Linux Fu: Use The Source (Command), Luke

March 13, 2025 by 12 Comments

You can argue if bash is a good programming language or not, but you can’t argue that it is a programming language. However, there are a few oddities about it that make it different from most other languages you probably know. For one thing, variables are dynamically scoped. Second, you can easily change variables in an upper scope. This leads to a problem when you want to do something like reset your path:

#!/bin/bash
#: This does NOT work
PATH=/usr/bin:/bin

Well, actually, it does work; it just doesn’t work the way you imagine it might. The key is to realize that when you execute our script (say, resetpath), a new copy of bash runs. It inherits all the variables from your shell. Now the script sets PATH for the new copy of bash. Anything else you run in that script will see your change. But when the script exits, the new copy of bash is gone and the old copy sees the same old PATH it always did.

Continue reading “Linux Fu: Use The Source (Command), Luke” →

Linux Fu: USB Everywhere

February 27, 2025 by 20 Comments

It is a common problem: I have a USB device on a computer out in the shop, and I want to use it from the comfort of my office. What to do? Well, you could remote desktop into the distant machine. But, honestly, I always find any remote desktop more than ssh clunky and somewhat undesirable. Fortunately, Linux can do virtually anything if you only know how to do it. So, this time, I’ll show you how to transport a USB device over your network. Of course, I have a network that reaches out to the shop. It should be a simple matter to tell my desktop machine that one of its USB devices lives across the network. Well, it wasn’t that simple, but it is doable.

The Tools

The whole thing involves a program called usbip. That should be the end of it, but of course, it isn’t. In order for this to work, both machines on the network will need some kernel modules and a daemon on the server: the machine with the USB devices to share.

You may be able to install usbip from your package manager. On Ubuntu, it is in the linux-tools-common package, so a simple apt-get might give you everything you need. I wasn’t so lucky. Continue reading “Linux Fu: USB Everywhere” →

Linux Fu: Audio Network Pipes

November 26, 2024 by 18 Comments

Life was simpler when everything your computer did was text-based. It is easy enough to shove data into one end of a pipe and take it out of the other. Sure, if the pipe extends across the network, you might have to call it a socket and take some special care. But how do you pipe all the data we care about these days? In particular, I found I wanted to transport audio from the output of one program to the input of another. Like most things in Linux, there are many ways you can get this done and — like most things in Linux — only some of those ways will work depending on your setup.

Why?

There are many reasons you might want to take an audio output and process it through a program that expects audio input. In my case, it was ham radio software. I’ve been working on making it possible to operate my station remotely. If all you want to do is talk, it is easy to find software that will connect you over the network.

However, if you want to do digital modes like PSK31, RTTY, or FT8, you may have a problem. The software to handle those modes all expect audio from a soundcard. They also want to send audio to a soundcard. But, in this case, the data is coming from a program.

Of course, one answer is to remote desktop into the computer directly connected to the radio. However, most remote desktop solutions aren’t made for high-fidelity and low-latency audio. Plus, it is nice to have apps running directly on your computer.

I’ll talk about how I’ve remoted my station in a future post, but for right now, just assume we want to get a program’s audio output into another program’s audio input. Continue reading “Linux Fu: Audio Network Pipes” →

Linux Fu: Failing Pipelines

July 25, 2024 by 16 Comments

Bash is great for automating little tasks, but sometimes a little script you think will take a minute to write turns into a half hour or more. This is the story of one of those half-hour scripts.

I have too many 3D printers. In particular, I have three that are almost — but not exactly — the same, so each one has a slightly different build process when I want to update their firmware. In all fairness, one of those printers is heading out the door soon, but I’ll probably still wind up building firmware images for it.

My initial process was painful. I have a special directory with the four files needed to configure Marlin for each machine. I copy all four files and ask PlatformIO to perform the build. Usually, it succeeds and gives me a file that looks like firmware-yyyyddmmhhmm.bin or something like that.

The problem is that the build process doesn’t know which of the three machines is the target: Sulu, Checkov, or Fraiser. (Long story.) So, I manually look at the file name, copy it, and rename it. Of course, this is an error-prone process, and I’m basically lazy, so I decided to write a script to do it. I figured it would take just a minute to bundle up all the steps. I was wrong.

Continue reading “Linux Fu: Failing Pipelines” →

Linux Fu: Kernel Modules Have Privileges

June 19, 2024 by 13 Comments

I did something recently I haven’t done in a long time: I recompiled the Linux kernel. There was a time when this was a common occurrence. You might want a feature that the default kernel didn’t support, or you might have an odd piece of hardware. But these days, in almost all the cases where you need something like this, you’ll use loadable kernel modules (LKM) instead. These are modules that the kernel can load and unload at run time, which means you can add that new device or strange file system without having to rebuild or even restart the kernel.

Normally, when you write programs for Linux, they don’t have any special permissions. You typically can’t do direct port I/O, for example, or arbitrarily access memory. The kernel, however, including modules, has no such restriction. That can make debugging modules tricky because you can easily bring the system to its knees. If possible, you might think about developing on a virtual machine until you have what you want. That way, an errant module just brings down your virtual machine. Continue reading “Linux Fu: Kernel Modules Have Privileges” →

Linux Fu: The Root Cause

May 21, 2024 by 22 Comments

There was a time when real system administrators just logged into Unix systems as root. But as we all know — with great power comes great responsibility. It’s too easy to do terrible things when you are really just trying to do normal work, and, on top of that, malicious software or scripts can do naughty things without you noticing. So common practice quickly changed to where an administrator had a personal account but then had a way to run certain programs “as root” which means you had to deliberately decide to wield your power.

Before long, people realized you don’t even need a root login account. That way, an attacker can’t try to log into root at all. Sure, they could still compromise your account, but a random hacker knows you might have a root user, but it is harder to guess that your login ID is JTKirkJr or whatever.

There are other ways to control what users can do, but many Linux and Unix installations still use this model. The root can do everything but login, and specific users get the privilege to do certain things.

Continue reading “Linux Fu: The Root Cause” →