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

> My recollection is that most CP/M programs were configured via patching. At least that’s how I configured them. I remember my WordStar manual coming with details about which bytes to patch to do what. There was also a few dozen bytes of patch space set aside for you to write your own subroutines, in case you needed to add custom support for your printer.

Huh. That is interesting, it was before my time, and I never heard of this :D

< Rewind to 1973. The operating system common on microcomputers was CP/M

OK. I love Raymond’s blog but this is crazy. Microcomputers existed only as a prototype in 1973 (things like Intel’s Intellec dev systems) and there were no operating systems for them. Strictly speaking, Kildall did start developing CP/M in 1973, but at that point it ran only on a simulator on a PDP-10 mainframe.

1979, sure. 1973? Way too early…

A great example of a decision that likely received little to no thought from an early developer but that has long legs and will stick around forever.

Also, chances are programs chose “TMP” because file extensions in MS-DOS were 3 characters, max, and programs used to use “.TMP” for names of temporary files.

It’s similar to how Unix programs weren’t consistent on whether they look for http_proxy or for HTTP_PROXY, and nowadays many(?) are looking for both, but maybe not in the same order.

I'm confused by the CP/M reference. Author says it'll be important later then proceeds to explain how it had nothing to do with CP/M or the 8080 CPU.

1995-ish. Telstra (Australia Telecom). Probably about 50k desktop computers across the organisation. One day a small file turned up in everyone's network home directory called null. A *nix person had evidently had a go at writing a .bat file.

Why do we need to adopt extant standards? (I was going to ask, why standardise? But realised that might confound the North Americans. : )

> My recollection is that most CP/M programs were configured via patching.

I honestly would have liked that better for a lot of programs than the dotfiles they litter all over my home directory.

I didn't know it was such a chaos.

So I guess the moral of the story is: Ensure they always point to the same path, or else...

I have been pointing out these annoying things for decades with Microsoft. It’s funny because the “senior dev” know it all there person always used to have an answer. “Heh you see temp stands for temporary. Tmp stands for troubleshoot my pc. For debug logs. That’s why I’m a senior and you’re not.”

As I’ve gotten more senior turns out I was right to question it and we can actually talk to the original Microsoft devs now and they explain the whoopsie and how they had to keep it for backwards compatibility.

So then I ask why that excuse is valid, backwards compatibility, when many changes are frequently breaking core compatibility and active business flow (like New Outlook) and they go full hands off. Whoah I’m not the bad dev you’ll have to ask the new guys.

You can’t ask the new guys. And they’re hiding behind leetcode screens. It’s no wonder why these real problems don’t get fixed and we have new outlook. It’s the senior dev from earlier who now works there. All the real devs are retired.

Even when I do get a real answer from Microsoft on annoying things like the user home documents folder being used inappropriately by random programs or straight up forcefully deleted by onedrive in an oopsie, their answer they senior dev invented to give me or go on length about in a technical document or angry interview online is invalidated within 6 months when Microsoft just vibe pushes a random change that randomly alters how these things work in both not a good way and it invalidates their entire core argument.

Just like notepad updates as another example off the top of my head. There are dev interviews talking about how this is a very simple program because it needs to be 0 risk. Then it gets a Microsoft auth login with copilot.

The whole leetcode dev attitude and Microsoft culture really ruins the entire industry. We can’t have civil discussions. Everything turns into Nuh uh your argument is invalid because you don’t work at Microsoft.

Google Chrome famously having chrome install into appdata to exploit and bypass admin rights is a core memory. That’s clearly not the actual intention of that feature for 3rd parties to use in order to bypass having administrator authority. But now this is retconned by the devs as an intended feature because chrome ended up being good at the time at having to sort out the mess of deploying a 3rd party exception program on millions of locked down business computers would’ve been a nightmare.

One of the first things I do (after using O&O ShutUp10++ of course) when setting a new installation is to create "C:\Temp\" folder and go to them variables to point there. Mind you, you have global TMP and TEMP, and you have user defined (which points to \Windows\Temp instead of %LOCALAPPDATA%/Temp) ones. All 4 will point to my folder and makes my life a lot easier in the long run

Environment variables on *nix are ... strange.

I noticed this first when I assigned TZ to .tar.xz (or .tar.gz) as I was lazy. Then things suddenly no longer worked. Turns out TZ is ... timezone. So you should not define all variables, right? Well ... how to know that? People can perhaps read tons of documentation, but I want to ... minimize time investment here. So I learn mostly by learn-and-doing. And as far as I know there is no trivial way to know about "this can be dangerous". Those shells are fairly simple at all times - and not that sophisticated.

TMP versus TEMP may also be trivial but ... who can remember the differences? And why is it important?

I have come to think that environment variables are useful; I use them all the time. But they are a bit hackish and not super-elegant and may have side effects. This is not a very important side effect per se, as most people will not run into issues such as TZ or having to think which variable to use and which not, but in the moment when you DO get surprising results, and you don't know why, this may become a problem suddenly. I kind of semi-work around by prefixing via:

   MY_

   MY_TEMP = /home/x/temp/

In my own ruby code I also have to use ENV[] sometimes, which is a wrapper over environment variables, but I also try to be as independent as possible from that. For instance, all my settings are stored in simple .yml files, and these are then used to autogenerate environment variables or handle things in environments where there are no environment variables available (this is sometimes the case; I had that issue with .cgi files many years ago, where I wanted to access all environment variables but for a reason I don't fully remember, this was not available. Then I transitioned into those .yml files and that problem went away; now of course I need to load those .yml files, if necessary, but this is trivial in ruby, YAML.load_file() works very well for the most part, and I find this is more reliable than depending on reading environment variables output. On some restricted environments this may be unavailable though; I had that on university campus running ancient linux systems, so I have to be flexible in this regard).

> These surface vibrations are so minute that they are not critical from a mechanical point of view (unlike e.g. vibrations due to imbalance), but they can cause serious acoustic problems. The reason for this is that when the fan is running, there is a pressure difference between the intake and the outlet side of the fan (lower pressure on the upside of the blades, higher pressure on the downside of the blades). From an aero-acoustic point of view, this situation is similar to a stereo speaker where there is higher pressure inside the chassis and lower pressure outside the chassis. In both cases, the pressure difference leads to an efficient acoustic coupling, so the surface vibration of either the blades of the fan or the membrane of the speaker is transferred to the air.

I love rotary woofers :) I hope to get one some day.

always shove it to `%LOCALAPPDATA%/Temp`, or `~/AppData/Local/Temp`, and don't think otherwise