shell script

16 Articles

Linux Fu: Yet Another Shell Script Trick

January 6, 2026 by 2 Comments

I’m going to go ahead and admit it: I really have too many tray icons. You know the ones. They sit on your taskbar, perhaps doing something in the background or, at least, giving you fingertip access to some service. You’d think that creating a custom tray icon would be hard, but on Linux, it can be surprisingly simple. Part of the reason is that the Freedesktop people created standards, so you don’t typically have to worry about how it works on KDE vs. GNOME or any of the other desktop environments. That’s a big win.

In fact, it is simple enough that you can even make your own tray icons with a lowly shell script. Well, of course, like most interesting shell scripts, you need some helper programs and, in this case, we’ll use YAD — which is “yet another dialog,” a derivative of Zenity. It’s a GTK program that may cause minor issues if you primarily use KDE, but they are nothing insurmountable.

The program is somewhat of a Swiss army knife. You can use it to make dialogs, file pickers, color selectors, printer dialogs, and even — in some versions — simple web browsers. We’ve seen plenty of tools to make pretty scripts, of course. However, the ability to quickly make good-looking taskbar icons is a big win compared to many other tools.

Docs

Depending on what you want to do, YAD will read things from a command line, a file, or standard input. There are dozens of options, and it is, honestly, fairly confusing. Luckily, [Ingemar Karlsson] wrote the Yad Guide, which is very digestible and full of examples.

Exactly what you need will depend on what you want to do. In my case, I want a tray icon that picks up the latest posts from my favorite website. You know. Hackaday?

Continue reading “Linux Fu: Yet Another Shell Script Trick” →

Tracing The #!: How The Linux Kernel Handles The Shebang

April 11, 2025 by 9 Comments

One of the delights in Bash, zsh, or whichever shell tickles your fancy in your OSS distribution of choice, is the ease of which you can use scripts. These can be shell scripts, or use the Perl, Python or another interpreter, as defined by the shebang (#!) at the beginning of the script. This signature is followed by the path to the interpreter, which can be /bin/sh for maximum compatibility across OSes, but how does this actually work? As [Bruno Croci] found while digging into this question, it is not the shell that interprets the shebang, but the kernel.

It’s easy enough to find out the basic execution sequence using strace after you run an executable shell script with said shebang in place. The first point is in execve, a syscall that gets one straight into the Linux kernel (fs/exec.c). Here the ‘binary program’ is analyzed for its executable format, which for the shell script gets us to binfmt_script.c. Incidentally the binfmt_misc.c source file provides an interesting detour as it concerns magic byte sequences to do something similar as a shebang.

As a bonus [Bruno] also digs into the difference between executing a script with shebang or running it in a shell (e.g. sh script.sh), before wrapping up with a look at where the execute permission on a shebang-ed shell script is checked.

A 6502, In The Shell

March 17, 2025 by 8 Comments

Shell scripting is an often forgotten programming environment, relegated to simple automation tasks and little else. In fact, it’s possible to achieve much more complex tasks in the shell. As an example, here’s [calebccf] with an emulated 6502 system in a busybox ash shell script.

What’s in the emulator? A simple 6502 system with RAM, ROM, and an emulated serial port on STDIO. It comes with the wozmon Apple 1 monitor and BASIC, making for a very mid-1970s experience. There’s even a built-in monitor and debugger, which from our memories of debugging hand-assembled 8-bit code back in the day, should be extremely useful.

Although the default machine has a generous 32k of RAM and 16k ROM, you can easily adjust these limits by editing machine.sh. In addition, you can get a log of execution via a socket if you like. Don’t expect it to run too fast, and we did have to adjust the #! line to get it to run on our system (we pointed it to bash, but your results may vary).

What you use this for is up to you, but we’re sure you’ll all agree it’s an impressive feat in the shell. It’s not the first time we’ve seen some impressive feats there, though. Our Linux Fu column does a lot with the shell if you want further inspiration.

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” →

Getting Linux Process List Without Forking Using Just A Bash Script

July 29, 2024 by 16 Comments

The ps command is extremely useful when you want to get some quick information on active system processes (hence the name), especially followed by piping it into grep and kin for some filtering. One gotcha is of course that ps doesn’t run in the current shell process, but is forked off into its own process, so what if everything goes wrong and you absolutely need to run ps aux on a system that is completely and utterly out of fresh process IDs to hand out? In that scenario, you fortunately can write a shell script that does the same, but all within the same shell, as [Isabella Bosia] did, with a Bash shell script.

The how and why is mostly covered in the shell script itself, using detailed comments. Initially the hope was to just read out and parse the contents of /proc/<pid>/status, but that doesn’t have details like CPU%. The result is a bit more parsing to get the desired result, as well as a significant amount of cussing in the comments. Even if it’s not entirely practical, as the odds of ending up on a system with zero free PIDs are probably between zero and NaN, but as an ‘entertaining’ job interview question and example of all the fun things one can do with shell scripting it’s definitely highly recommended.

Linux Fu: Mixing Bash And Python

May 4, 2021 by 24 Comments

Although bash scripts are regularly maligned, they do have a certain simplicity and ease of creation that makes them hard to resist. But sometimes you really need to do some heavy lifting in another language. I’ll talk about Python, but actually, you can use many different languages with this technique, although you might need a little adaptation, depending on your language of choice.

Of course, you don’t have to do anything special to call another program from a bash script. After all, that’s what it’s mainly used for: calling other programs. However, it isn’t very handy to have your script spread out over multiple files. They can get out of sync and if you want to send it to someone or another machine, you have to remember what to get. It is nicer to have everything in one file.

Continue reading “Linux Fu: Mixing Bash And Python” →

Linux-Fu: One At A Time, Please! Critical Sections In Bash Scripts

August 18, 2020 by 12 Comments

You normally think of a critical section — that is, a piece of a program that excludes other programs from using a resource — as a pretty advanced technique. You certainly don’t often think of them as part of shell scripting but it turns out they are surprisingly useful for certain scripts. Most often, a critical section is protecting some system resource like a shared memory location, but there are cases where a shell script needs similar protection. Luckily, it is really easy to add critical sections to shell scripts, and I’ll show you how.

Sometimes Scripts Need to Be Selfish

One very common case is where you want a script to run exactly one time. If the same script runs again while the original is active, you want to exit after possibly printing a message. Another common case is when you are updating some file and you need undisturbed access while making the change.

That was actually the case that got me thinking about this. I have a script — may be the subject of a future Linux-Fu — that provides dynamic DNS by altering a configuration file for the DNS server. If two copies of the script run at the same time, it is important that only one of them does modifications. The second copy can run after the first is totally complete.

Continue reading “Linux-Fu: One At A Time, Please! Critical Sections In Bash Scripts” →