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.
Why are there both TMP and TEMP environment variables? (2015)
51–60 of 102 posts
Re: Why are there both TMP and TEMP environment variables? (2015)
#52OK. 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…
[deleted]
Re: Why are there both TMP and TEMP environment variables? (2015)
#53Earlier quoted context omitted.
Except that DOS was made to have its first programs ported from CP/M, so it’s relevant to explain that there were no environment variables to inherit from CP/M and no developer habits or program standards to inherit from CP/M programs.
Which is irrelevant to TMP or TEMP. It could simply be: When envars were added to MSDOS…
Multics had envars in the 1960s and Unix in the 1970s, why were they ‘added’ to DOS when it was so close to an older OS, why didn’t it inherit them from CP/M? Did it get TMP from CP/M and introduce TEMP because computers were bigger but then?
Re: Why are there both TMP and TEMP environment variables? (2015)
#54Environment 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 k…
I use lowercase for my personal environment variables. It works well since most programs only depend on variables in all caps. Hadn't thought of using MY_
Re: Why are there both TMP and TEMP environment variables? (2015)
#55OK. 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…
Wikipedia says it was created in 1974, so something's definitely off with the time line here.
Intel 8080 was launched in April 1974 and the development system for it, "Intellec 8 Mod 80", was available soon after that.
CP/M could be developed only after the launch of the 8080 and the delivery of the development system.
In UNIX, the environment variables were added in the Seventh Edition (1979-01), together with the Bourne shell.
I do not remember whether any other command interpreters used something equivalent with environment variables before the UNIX shell (excluding the interpreters for general-purpose programming languages, like LISP and APL, where you can run a function in REPL and that function can access global variables).
Therefore the quoted year may be a typo for 1979, when environment variables appeared in the UNIX shell, but were not available in the CP/M Console Command Processor (CCP, the predecessor of COMMAND.COM).
Re: Why are there both TMP and TEMP environment variables? (2015)
#56Environment 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 k…
I prefer aboard_varname, because my_ is sometimes used by people like you ;-).
Re: Why are there both TMP and TEMP environment variables? (2015)
#57Earlier quoted context omitted.
"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."
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…
Sounds like the short answer is "because there was no standard for the variable set by MS-DOS from the get go".
The background is that the issue hadn't existed in CP/M because there hadn't been environment variables. Perhaps if the issue had already been seen in CP/M, the developers of MS-DOS might have defined a standard variable to avoid it. Maybe. Other than that it doesn't seem to have much to do with CP/M specifically.
Re: Why are there both TMP and TEMP environment variables? (2015)
#58> 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.
Well, they are supposed to be all in .config, problem is many app developers think they are special little boys that deserve its own directory
Most modern software uses .config, and I suspect the holdouts are due to cross-platform support issues. Windows may have it's own equivalents, but they are radically different from Unix. Developers may not want to deal with those differences, or don't want to deal with the support issues related to those differences.
The remaining holdouts tend to be very old applications. (The XDG standards are less than 25 years old, then you have to give time for them to be adopted.) For some of those applications, it would create support issues even if it would be trivial to implement. For others, it would create issues since other software would have to be modified to reflect the changes. For others, the software did not have a distinct configuration directory so untangling it would be a major effort.
In the case of the latter, just look at Firefox. Yes, it recently moved the .mozilla directory to .config. It is in no way reflective of the XDG standards. Among other things, there are log files, cache files, and add-ons in there. In my mind, that is worse than having ~/.mozilla. Instead of having a directory that can be cleanly backed up, with the exceptions being elsewhere, I am left having to sort through everything. I don't blame Firefox for taking that approach though: users were demanding a clean home directory and the developers had legacy code to deal with. They simply took the path of least resistance. (That said, Firefox isn't the only culprit here.)
Re: Why are there both TMP and TEMP environment variables? (2015)
#59Earlier quoted context omitted.
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.
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…
Cool, yeah, he had the 16 kb extension and his own software written on a cassette/tape.
He says hi back, for him it was purely a work machine (PhD in Chemistry, never did anything with computers as in CompSci), he doesn’t remember too much from back then but he said he loved the architecture of it.
Re: Why are there both TMP and TEMP environment variables? (2015)
#60> 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…
Some sort of still do. The stuff that suckless writes is generally configured by changing config.h and recompiling.
Edit: oops just saw that this was already mentioned in another subthread on this page.