arch-lwc VS urlscan

I wrote a little tool to make creating and interacting with systemd-nspawn containers easier (on arch Linux only right now):

https://github.com/b0o/arch-lwc

Not intended for any sort of production. I personally use it to run Firefox inside a container and for testing.

Well, if it's text, you can use a program like urlscan which extracts URLs from input text and allows you to launch them in your browser of choice.

You all joke that this doesn’t happen in practice, but this literally just happened to me and it took me a few minutes to figure out what was going on.

The article lists Bash as not suffering from the bug, but it actually does if you `set -e`.

I use a bash script as my BROWSER which calls another bash script to launch or communicate with my browser that I run inside a container. The script that my BROWSER script calls has some debug output that it prints to stderr.

I use mutt as my email client and urlscan [0] to open URLs inside emails. Urlscan looks at my BROWSER environment variable and thus calls my script to open whatever URL I target. Some time recently, the urlscan author improved the UX by hiding stderr so that it wouldn’t pollute the view, and so attempted to pipe it to `/dev/null`. I guess their original code to do this wasn’t quite correct and it ended up closing the child processes’ stderr.*

I generally use `set -e` because I want my scripts to fail if any command fails (I consider that after a an unhandled failure the scripts behavior is undefined, some other people disagree and say you should never use `set -e` outside of development, but I digress). My BROWSER scripts are no exception.

While my scripts handle non-zero returns for most things that can go wrong, I never considered that writing log messages to stdout or stderr might fail. But it did, and for a few weeks I wasn’t able to use urlscan to open links. I was too lazy to figure out what was wrong, and when I did it took me a while because I looked into every possibility except this one.

Luckily this wasn’t a production app. But I know now it could just as feasibly happen in production, too.

I opened an issue[1] and it was fixed very quickly. I love open source!

*No disrespect to urlscan, it’s an awesome tool and bugs happen to all of us!

[0]: https://github.com/firecat53/urlscan