Blog entries :: mwop.net

Determining if a reboot is required on Linux

2026-05-04T08:35:08-05:00

I've been using the construct sudo run-parts /etc/update-motd.d/ to determine if recent system updates required a reboot. Today I learned I can simply check for the existence of the file /var/run/reboot-required. Determining if a reboot is required on Linux was originally published 4 May 2026 on https://mwop.net by Matthew Weier O'Phinney.

PHP DateTimeImmutable::createFromFormat Reset Character

2026-04-16T10:30:00-05:00

I was recently building something that was taking date input from an HTML form field, and casting it to a PHP DateTimeImmutable. I was then comparing that to another date, and got thrown off during testing when I compared the resulting instance to new DateTimeImmutable('today'); the instances were not considered equal. To recreate the conditions, you can try the following: $date = '2016-06-16'; $fromForm = DateTimeImmutable::createFromFormat('Y-m-d', $date); $today = new DateTimeImmutable('today'); echo $fromForm == $today ? 'Equal' : 'Not equal'; // outputs "Not equal" What's happening? Well, if you were to echo the results of each of $fromForm->format('c') and $today->format('c'), the difference is clear: the $fromForm value includes the time when the instance was created, while $today has the time set to midnight. So, how do you zero out the time when using createFromFormat()? It turns out that one of the format characters you can use is the | operator. When you include this at the end of your format string, any fields not included in the format are zero'ed out: $fromForm = DateTimeImmutable::createFromFormat('Y-m-d|'); Reference DateTimeImmutable::createFromFormat() Parameters PHP DateTimeImmutable::createFromFormat Reset Character was originally published 16 April 2026 on https://mwop.net by Matthew Weier O'Phinney.

SQL ENUM Modification

2026-04-08T15:34:00-05:00

I'm doing a little DB work recently, and needing to choose how to represent certain data in the database. For a few fields, ENUM would be the correct choice, but there's a possibility I would need to expand the ENUM later to add values. My question: is this safe? The short answer, in my research, is "yes", but with caveats. For Postgres, it's trivial; you can easily add values to ENUM types: ALTER TYPE some_previously_defined_enum ADD VALUE 'new-value'; For MySQL, it's a bit more complex. ENUMs are defined within the table schema, and to change them, you use an ALTER TABLE statement: ALTER TABLE some_table MODIFY some_previously_defined_enum ENUM('value-1','value-2'); Essentially, you're replacing the definition. This is fine... so long as you don't change the order, or remove any previously defined value in the ENUM. In other words, append to the existing list if you want to safely change it. SQL ENUM Modification was originally published 8 April 2026 on https://mwop.net by Matthew Weier O'Phinney.

CSS Grid Lanes

2026-04-07T10:38:00-05:00

I've been using the experimental "display: masonry" CSS for my gallery and a few other areas of my website for over a year (with a fallback to standard grid columns). However, I noticed in the last few months that my browser was no longer honoring it, and finally researched what happened. It turns out it's been renamed to "display: grid-lanes" in the CSS Grid Level 3 specification. Otherwise, everything else remains the same; continue using grid-template-columns and grid-template-rows as you did with the the masonry display. Safari has it in preview already, while Firefox and Chrome-based browsers have it behind a flag. (On Chrome-based browsers, visit chrome://flags, and enable the "css-grid-lanes-layout" flag.) CSS Grid Lanes was originally published 7 April 2026 on https://mwop.net by Matthew Weier O'Phinney.

Headless boot for Beelink EQ14

2026-02-24T10:09:08-06:00

A few months back, I purchased a Beelink EQ14 mini server for my homelab. One thing that has frustrated me has been that rebooting or even powering on... has required I have either my keyboard or my monitor plugged in (I haven't been able to determine exactly which one yet). This has made me reluctant to reboot, as I then have to switch my keyboard from my workstation over to the server, and plug the HDMI from one of my monitors into it. I hate it. In browsing a number of forums, I saw one recommendation to switch the BIOS to use FastBoot. Can confirm, works! Update While FastBoot helps, it doesn't entirely fix the issues. What I discovered was that the server was requiring my keyboard in order to boot; I tested this by rebooting the machine without cables, and plugging in only the keyboard. Unfortunately, there are no BIOS settings to override this behavior. I dug up an old USB dongle for a presentation pointer, plugged that in, and voilá — it boots now. I suspect any USB HID dongle will likely work. Headless boot for Beelink EQ14 was originally published 24 February 2026 on https://mwop.net by Matthew Weier O'Phinney.

Globbing files to pass to CLI command options

2026-02-18T13:56:00-06:00

I've been using Helm recently as part of a new product offering, and as a way to deploy my various websites. Helm allows providing values to the templates in a Helm chart via one or more values files, which are provided via the option -f. It's often useful to break these into several files, so you can do things like cover common values, and then environment- or namespace-specific values. However, the -f option only accepts a single value, and doesn't recognize globs. The printf solution The solution is to pass the glob to printf, with the format '-f %s '. This will print out an option per file. When in a terminal, this can be done using printf within a subshell. Now how you do that depends on the shell, because the -f in our format string can be interpreted as an option/flag to printf itself depending on the shell. For bash, we can do this: helm upgrade -n qa . $(printf -- '-f % ' *.values.yaml) This is because printf in bash will emit an error for any unknown option/flag it encounters; the -- tells the command when the end of all options/flags have been reached, so that it treats the remainder as arguments. For fish, we don't need the --, as the printf implementation in fish doesn't accept arguments anyways: helm upgrade -n qa . $(printf '-f % ' *.values.yaml) Makefile Of course, subshells in a Makefile require a little change as well. In a Makefile, I write the above as: helm upgrade -n qa . $(shell printf -- '-f %' *.values.yaml) (And since I also declare SHELL=/bin/bash at the top of my Makefile, I have to use the -- trick here.) Globbing files to pass to CLI command options was originally published 18 February 2026 on https://mwop.net by Matthew Weier O'Phinney.

Passing script arguments to a Makefile target

2026-02-11T10:41:53-06:00

I've many times wondered how I could build a Makefile that would accept arguments to pass to the command invoked by the build target. It turns out to be relatively easy. There is a make variable called MAKECMDGOALS that contains the list of possible build targets. We can filter-out any of those from the arguments passed to make (as referenced by $@) to get a list of command arguments to pass on to our program. #!make SHELL := /bin/bash .PHONY: hello default: help hello: # Hello world @echo "Hello," $(filter-out $@,$(MAKECMDGOALS)) %: # catch-all target to ignore argument "targets" @: # no-op From here, if I invoke make hello world, it will spit out Hello, world. But what about if you want to pass a flag or option? Add a -- before any flags or options so that make won't treat them as its own options. (That said, I've had limited success with this. References I learned this technique via a blog post on CodeGenes. Passing script arguments to a Makefile target was originally published 11 February 2026 on https://mwop.net by Matthew Weier O'Phinney.

When docker buildx cannot resolve your container registry

2026-02-11T09:49:31-06:00

I had an odd situation today when building and pushing a container image to a registry. I have a private registry in my homelab. I have an internal DNS server that can resolve it when in my home network, and my machines in my home network all use that internal DNS server. Great, fantastic, just works. Except for some reason, when running a docker buildx build --push operation, it was unable to resolve the internal name... because it was using the wrong DNS server. It was trying to resolve via the 8.8.8.8 DNS server. The Google DNS servers. Which I've not even configured as an upstream in my recursive DNS server on the local network. My guess is that the Docker daemon falls back to Google DNS servers if the system DNS cannot be reached at any point. Clearly, it then never tests to see if the system DNS has become reachable again, so it gets stuck there. The solution? Restart the docker service: sudo systemctl restart docker Once I did that, it resolved using the system DNS next time. When docker buildx cannot resolve your container registry was originally published 11 February 2026 on https://mwop.net by Matthew Weier O'Phinney.

Removing a filename containing a null byte or binary character on Linux

2026-02-06T11:01:27-06:00

Somehow, I got a file in my tree that started with a null byte. I only discovered it because git status was noting it wasn't added to my branch, and wanted to know if I wanted to add it. No, no, I did not. I wanted to delete it. But, of course, you cannot reference such a file by name, so I had to learn a few tricks. First off, you can list names with binary bytes using: /bin/ls -lb But even better, you can get the inode if you use: /bin/ls -li When you do, the inode is in the first column of the list for each file. Once you know that, you can delete the file, using find: find . -maxdepth 1 -inum -exec rm -i -- {} + Removing a filename containing a null byte or binary character on Linux was originally published 6 February 2026 on https://mwop.net by Matthew Weier O'Phinney.

From zsh to fish

2025-11-17T17:00:10-06:00

I'm a longtime zsh user. A colleague introduced me to it in 2009, and I was an instant convert, if nothing else than for directory aliases and simpler $PATH management. Within a couple of years, I discovered oh-my-zsh, which put my shell on steroids, giving me a ton of completion capabilities, better prompts, and more. But a few years ago, I started noticing that my shell load times were getting worse and worse. At that time, I discovered I could easily switch to vanilla zsh with zplug managing a small number of plugins I used (nvm, fzf, and a few others). I also discovered starship, which gave me more prompt options, with faster startup times. And yet... I kept reading Julia Evans recommending fish. She often would note that fish just does things that other shells need plugins or customization for: decent tab completion, better history capabilities, etc. So I took the plunge finally in the past couple weeks to give fish a try. Configuration First off, the switch more than halved the amount of configuration I needed to have an equivalent setup. I was able to remove a ton of configuration I had in zsh around history management, autocompletion, and overrides. As I noted, with zsh, I was using zplug, and I had a half-dozen plugins. With fish, initially I had no plugins, but in order to get nvm running, I needed to install fisher, the de facto fish plugin manager. But that's literally the only plugin I'm now using. I continued to use starship and fzf, which meant two lines of configuration in my fish configuration, and no changes otherwise. And there's no lag whatsoever when starting up a shell. With zsh, even with my minimal config, I would sometimes wait a second or two for a shell to spawn. With fish, no wait. Discoveries One thing I've kept from oh-my-zsh is a utility called take, which does the following: If given a directory name, it creates it, and then enters it If given an archive file, it unarchives it into a directory, and then enters that directory If given a git repository name, it clones it, and then enters that directory When porting this to fish, I discovered some really cool features of that shell. First, fish will automatically autoload functions from the functions/ subdirectory of your fish configuration. So if you name the function the same as the file (e.g., functions/take.fish), it will load it on demand. This is a nice performance improvement over loading everything. Second, fish uses a standard syntax for any block statement. Instead of sometimes needing braces, sometimes needing a keyword (which generally varies BASED on the block type - e.g. fi to end a conditional, done to end a loop), all blocks use an end keyword. This makes it far simpler to remember and less prone to errors. Third, when defining a function, you can specify variable names to which to capture arguments. This is far easier to visually parse and use than standard posix shells, where you use positional parameters. As an example: function takedir -a newpath mkdir -p $newpath && cd $newpath end Fourth, while you can use the notation varname=value to define variables, there's a better built-in, the set directive, which can: Define block-local (set -l) and function-local (set -f) variables Define globally-available variables (set -g) Define environment variables (set -x, for export) that persist to child shells Using this, it's far easier both to ensure that a variable is scoped correctly, as well as to reason about the scope of a given variable. And those captured arguments I mentioned? Automatically scoped to the function, so they won't bleed outside of it. (There's also a "univeral" flag, -u, which will not only set it in the current shell, at the globally available level, but make it available across any other instances, and persist it for future invocations. This seems dangerous, though!) The combination of these meant that the take declaration took fewer lines of code, was easier to understand, and less likely to bleed state. I'll take it! But will I stick with it? I think so. I even put it on some servers I maintain, and it's instantly given me more and better functionality than the default shell available on each, which makes being on those servers more comfortable. Having less configuration is something I've been keeping an eye on, as more configuration means it's harder to reason about how things work, and more likely to break or fail in interesting ways when updating or upgrading. I'll still need to keep my bash chops; provisioning scripts for containers and VMs generally have to depend on this lowest common denominator. However, having a useful out-of-the-box shell for my workstation and servers that's easy to script? I'll take it. From zsh to fish was originally published 17 November 2025 on https://mwop.net by Matthew Weier O'Phinney.