Stuff like that is also cool (reminds me a bit of modding some games), patching machine code to improve performance of a compiled app? Very cool! (My dad might have done that, he has an old ZX81)

But I thought specifically patching something to configure it is such a weird concept that I never would have thought of.

"Rewind to 1973. The operating system common on microcomputers was CP/M. The CP/M operating system had no environment variables. That sounds like a strange place to start a discussion of environment variables, but it’s actually important."

I contemplated for years and eventually saw someone implement a transparent kernel redirect for programs reaching for ~/.*

Ohh acquired taste it is.. I had two stints with suckless software. First, when i was in early twenties when I had a lot of time in the world, and thought the manliest way to talk to a machine is all through low level C code. Had a whole flow to patch it and heck the code is so well written and commented, i was able to understand it. Then, i guess life happened and i discovered more interesting stuff to spend time on.

And now in my late twenties, suckless terminal is the only one that would work reliably on a shitty old enterprise linux system at work. Yeah, we got xterm and konsole (the older one). I am seeing them in a whole different light now. I did not read the source code now and it is effectively a foreign language to me, but just being able to have modern features in it without too many dependencies is a different level of bliss. This time, I am glad I have the flexi patch to the rescue since, i passed on suckless terminal as a real alternative since I don’t want to patch it manually or solve merge conflicts!

Even though I don’t like the elitist attitude of the project, can’t deny they got a point. Why does a terminal emulator need to be so complicated!

https://github.com/bakkeby/st-flexipatch

%LOCALAPPDATA% on Windows. Or better still, use GetAppContainerFolderPath or SHGetKnownFolderPath with FOLDERID_LocalAppData.

It all sounds so easy, until you learn about the XDG Base Directory Specification[1]. You're actually supposed to do a whole song and dance around a hierarchical set of environment variables, associated defaults, and resolution orders.

Interfacing with people is never easy.

[1]: https://specifications.freedesktop.org/basedir/latest/

As these things go, there obviously is a standard for this called the XDG Base Directory Specification[0], which elegantly solves almost all configuration path needs—and has been ignored, violated, or only partially implemented, since forever.

[0]: https://specifications.freedesktop.org/basedir/latest/

Fun fact: "/dev/nul" (with only one L) would have worked, even if there is no directory with that name.

That's been a feature since DOS 2.0, there was even an undocumented option AVAILDEV to make the prefix mandatory, instead of having device names present everywhere. But it broke the common trick used to detect if a directory exists ("if exist c:\some\path\nul").

Unix programmer remembered that in there's no /dev/null in DOS and that it's something shorter, and tried null which worked. Didn't check the directory contents afterwards. So basically your first sentence - doesn't seem at all unlikely to me. (I mean, I think it happened to me at least once too)

I've already created a 'NULL' file, but it was not a Unix thing... It was just because I got confused if it was NULL as in the programming languages I usually use.