Why are there both TMP and TEMP environment variables, and which one is right? | Hacker News Reader

Why are there both TMP and TEMP environment variables, and which one is right?

blogs.msdn.com

63 pointscremno14 comments

> Many programs tried to appease both sides of the conflict by checking for both, and it was up to the mood of the original author which one it checked first. For example, the old DISKCOPY and EDIT programs would look for TEMP before looking for TMP.

> Windows went through a similar exercise, but for whatever reason, the original authors of the GetTempFileName function chose to look for TMP before looking for TEMP.

For what it's worth, Python, which also supports Unix-like systems, checks for 'TMPDIR', 'TEMP', and then 'TMP'.

> For what it's worth, Python, which also supports Unix-like systems, checks for 'TMPDIR', 'TEMP', and then 'TMP'.

Python checks TEMP and TMP for Windows compatibility; Linux programs standardized on TMPDIR (to the extent they don't incorrectly hardcode /tmp).

What's a bit unusual about Python is that it tries all three environment variables on every OS. I would have expected that it would only try TMPDIR on Unix-like machines, and TMP/TEMP on Windows-based machines. There's no compatibility expectation that Windows environment variables would work on Unix-like OSes, or vice versa.

FWIW, TMPDIR was part of standard Unix practices before Torvalds wrote the first line of the Linux kernel. For example, 4.3BSD-Reno came out 1990 . If you grab the tape from http://sourceforge.net/projects/bsd42/files/Install%20tapes/... and page through it you'll see the man pages were "Printed 7/27/90" and contain things like:

     If the environment variable TMPDIR is set, the string
     denoted by TMPDIR will be used as the name of the directory
     where the temporary files are created.
          -- yacc(1)

     The environmental variable ``TMPDIR'' (if set), the argument
     dir (if non-NULL), the directory ``/usr/tmp'' and the direc-
     tory ``/tmp'' are tried, in the listed order, as directories
     in which to store the temporary file.
          -- TMPFILE(3)

Python comes out of the Unix heritage (van Rossum contributed the glob() routine to BSD Unix in 1986), which is likely why the first commit of tempfile.py, Nov. 12 1991, mentions TMPDIR, though it didn't actually support the environment variable until Jan 14 1992.

OTOH, it didn't gain TMP/TEMP support until Aug 12 1997. Even then, the file says at the top:

  # XXX This tries to be not UNIX specific, but I don't know beans about
  # how to choose a temp directory or filename on MS-DOS or other
  # systems so it may have to be changed...

"The nice thing about standards is that you have so many to choose from" - Andrew S. Tanenbaum

I could have sworn I have seen that quote attributed to somebody else, but I have forgotten who.

Either way, it is a pearl of wisdom. ;-)

One of the nice things about this quote is that you have so many authors to choose from.

Nice one! Good thing I wasn't drinking tea when I read this, I would have ruined my keyboard. ;-)

The explanation for any strange behavior by a Microsoft program is almost always "to maintain compatibility with legacy applications." It's not entirely unique to Microsoft, but they're pretty obsessed with not breaking things.

People keep saying that they're obsessed with it, yet I've had better results running an (admittedly, quite old) booking system under dosbox on Linux than on Windows post-XP. And I regularly advise people to try LibreOffice when Word refuses to open old documents properly. YMMV.

They also didn't hesitate to break pretty much all TCP/IP using userland with the firewall transition in XP SP2. Which was the right thing to do at the time, mind you, just not terribly conservative.

Linux still runs a.out binaries (and that transition was in only in '96), but they still have quite a bit to go in comparison to a S/360 which runs JCL programs from '78 unmodified. That's obsession for you.

AFAIK the worst at compatibility is Word 2011 for Mac. It wasn't difficult for example to find Mac Word 5.1 documents that open perfectly fine in Word 2010 for Windows (after unblocking the file format) which would display nothing but garbage when opened in Word 2011 for Mac.

Linux does run a.out binaries, but every odd minor revision of glibc breaks the ABI.

Yes, Dosbox does have better compatibility with old systems than Windows, but it's only job is providing compatibility. This is not a fair comparison. (The LibreOffice comparison is completely fair, Office is simply bad at maintaining compatibility - and almost everything else.)

Well, Windows also keeps compatibility layers whose only job it is to run legacy code. If a handful of enthusiasts can do a better job on a completely different underlying operating system, they have obvious improvement possibilities.

The curse of Linux is that every moving part is its own project. Libc and the gcc C++ API is notoriously problematic with backwards compatibility, so the backwards compatbility of Linux as a whole is also restricted.

I just want to question the often-repeated picture of Microsoft as obsessed with backwards compatiblity. Where does that idea come from? I'm just not seeing it at all. A new Windows box will not even authenticate with a too old AD server. If you want examples of backwards compatibility, look at S/360, AS/400, VAXen, pretty much any other operating system with an enterprise prescence.

I feel kind of weird saying good things about Microsoft, but for better or worse, they have done a really impressive job about maintaining backward compatibility.

Given the horrors their programmers must face in the name of this objective, I imagine they are not obsessed about it for its own sake, but because of legions of customers running badly written legacy applications they cannot or will not change, who will get very angry if Microsoft breaks their precious applications.

Just remember the uproar when Service Pack 2 for Windows XP was released, where Microsoft deliberately broke compatibility to improve security.

There's a similar quirk with the env variables used to set a proxy hostname - http_proxy vs HTTP_PROXY. On Unix environment variable names are case sensitive, $foo is distinct from $FOO. The strong convention is to use upper-case only. Some early command line http client (possible lynx) chose to buck the trend and used lower-case.

Now some programs check the upper-case variant, some the lower, and some check both. So if you set one, you should set the other to avoid confusion.

https://wiki.archlinux.org/index.php/proxy_settings#Environm...

Does anyone know of a full write-up of the history of this?

Reply on news.ycombinator.com