Why are there both TMP and TEMP environment variables? (2015)

The ZX81 didn't have so much software around for it - what there was mostly came on tape, or was typed in¹ on the ghastly membrane keyboard, and what there was was very limited in capability (the default RAM size was one kilobyte (yes, just 1024 bytes, though typically you'd buy a "ram pack" upgrade to 16k). Then it was very rapidly superseded by the more capable ZX Spectrum machine. So odds are your Dad didn't patch software on the ZX81 because it was usually already highly optimised to squeeze it into the tiny space available.

What was very common on those devices was using the "poke" command in BASIC to change a handful of values, but while it was possible to change code in this way it was much more common to be changing the value of variables - things corresponding to "number of lives left" and the like. Not all that different.

Fairly quickly, though, the games were entirely in machine code and used fancy loaders (still from tape mostly) so you didn't get access to BASIC. This created a market for devices that let you get at a monitor program - the "Multiface" series of addons². They had at least three generations of that device, but the company slightly weirdly evolved into a music production company³ after that, which is kind of cool.

Er, ok, I'll stop now while I still can...

Edit: PS - you should ask him about it. Tell him another former ZX81 owner says "Hi" and that my fingers still ache from that keyboard. Although I sneer a bit at its capabilities, it kicked off an interest in computing that's still paying the bills 40 something years later...

----

¹ https://spectrumcomputing.co.uk/entry/2000265/Book/Not_Only_...

² https://en.wikipedia.org/wiki/Multiface

³ https://en.wikipedia.org/wiki/Romantic_Robot

The line between "configuration" and "modding" is pretty thin.

One could say that the difference is whether the developers intended the changes you're making to be possible or not, but what about programs with dedicated modding APIs?

> I don’t want to patch it manually or solve merge conflicts

I wonder, is this really such a big problem? How often do people add patches or change their config?

I've configured my st once and haven't touched that build for years. I use only few patches like scrollback, custom colortheme and a "plumb" for few scripts.

I've also had an opportunity recently, to try a "modern" and trendy terminal and I can't see myself switching to something slower (in terms of lag) and using 10x more memory and cpu even when idle for literally zero gain.

A few years ago I had a Windows box where I pointed XDG_CONFIG_HOME et al to the corresponding-ish Windows paths (AppData subdirectories, mostly) so that the many Linux-derived CLI programs I was using wouldn't clutter up my userdir, and it worked pretty well, though there were a few programs that didn't get the memo. Unfortunately I don't remember which ones they were. Most programs get it right, though!

I don't know if anyone is actually using roaming profiles, but config should go into the %APPDATA% folder to support that. %LOCALAPPDATA% is for things that shouldn't be synced to different machines, such as caches.

No. Actually, it's easy. Just check for directory or use a fallback. For example here's how you'd do this in bash:

    export CONFIG_DIR="${XDG_CONFIG_HOME:-$HOME/.config}"
    export CACHE_DIR="${XDG_CACHE_HOME:-$HOME/.cache}"
    ...

XDG_*_DIRS are a bit more complicated, but nothing that can't be solved with a simple for-loop in any modern programming language.

Say what you want about AI but one nice aspect of it is that it is more likely to follow these kinds of standards than humans.

Just a few lines below:

"Over time, programs were written with MS-DOS as their primary target, and they started to realize that they could use environment variables as a way to store configuration data. In the ensuing chaos of the marketplace, two environment variables emerged as the front-runners for specifying where temporary files should go: TEMP and TMP."

And before that there are a few paragraphs describing the migration of applications from i8080/Z80 based CP/M towards x86 based DOS via mechanical translation.