apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: APR_TMP_DIRECTORY
Date Thu, 05 Dec 2002 21:26:28 GMT


On Thu, 5 Dec 2002, Aaron Bannert wrote:

>
> On Thursday, December 5, 2002, at 01:07  PM, <rbb@apache.org> wrote:
> > What exactly is the argument against using the proposed API?  That we
> > shouldn't use environment variables?  The environment variables are a
> > mechanism that some platforms use for locating the temp directory.  To
> > ignore them would be stupid and it would make it harder to APR app
> > developers to write their code.
>
> Unix does not use environment variables for locating a temp directory.
> That's fine if Windows does that, and that's fine if some Unix apps
> decide they want to do it that way, but it is not standard and it
> not defensive system programming.
>
> Can anyone think of a case where temp files on Unix do not belong in
> either 1) /tmp or 2) a user-defined location?

I know of a couple of Unix platforms that use /var/tmp, yes.  But more
importantly, what makes you think Unix doesn't use environment variables
for locating a temp directory?  Try doing a man on tempfile some time.  I
quote:

       The directory to place the file is  searched  for  in  the
       following order:

       a)     The directory specified by the environment variable
              TMPDIR, if it is writable.

       b)     The directory specified by  the  --directory  argu-
              ment, if given.

       c)     The directory /tmp.

That's Linux, and it is a standard utility to create temporary files.  It
is looking for an environment variable first.

Like I said, different Unix platforms have different mechanisms for
locating temporary directories, (although I have never seen one that
didn't use $(TEMP) as a fallback).  Leave it up to the platform to locate
temp files if the user doesn't provide one.  Don't force the user to jump
through hoops to setup a default, the platform has already done that for
us.

Ryan


Mime
View raw message