Re: [boost] [filesystem] temp_dir_path()

Subject: Re: [boost] [filesystem] temp_dir_path()
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2010-10-11 09:19:01

Stewart, Robert wrote:
> Jeff Flinn wrote:
>> Ulrich Eckhardt wrote:
>>> On Saturday 09 October 2010 18:36:23 Jeff Flinn wrote:
>>>> Posix relies on getEnv("TMPDIR"), which returns 0 if the
>>>> environment variable does not exist.
>>> Question on that: Is it POSIX that actually mandates this
>>> very name anywhere?
>>>
>>> In my experience, there are actually four of these TMP,
>>> TEMP, TMPDIR and TEMPDIR.
>> http://en.wikipedia.org/wiki/TMPDIR calls TMPDIR the "canonical Unix
>> environment variable" and refers to the following for that
>> justification:
>>
>> <http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_03>
>>
>> On Mac OSX TMPDIR refers to the users temp folder.
> 
> This is curious.  I've never set that variable, to my recollection, but have used TMP instead in my long years of using IRIX, Sun OS, Solaris, and Linux.  It may well be that all of those OSes would have accepted both equally and, perhaps, even looked for TMPDIR first, but I've found TMP to work well and referencing only TMPDIR would break in my environment.  I used set to verify my current environment and TMPDIR is not set by me or on my behalf.
> 
> Granted, knowing the requirement or temp_dir_path(), I could readily correct my environment to fit, but it seems like trying the common e-vars would be a friendlier approach.

Is there any consensus on this? What order should they be checked? Given 
the above links, I'd say TMPDIR should be first.

How about: TMPDIR, TMP, TEMP, TEMPDIR?

>>>> - should Windows provide a more 'temp-path' centric error?
>>> I wouldn't bother. If someone needs this, they will
>>> probably file a bug ticket.
> 
> The two platforms should report the condition consistently, shouldn't they?
> 
>>>> - should both verify the path exists?
>>> Yes. Question remains what fallbacks should be tried, e.g.
>>> "/tmp" on POSIX systems or environment variables on
>>> non-embedded win32.
>> Is the above reference sufficient to only rely on TMPDIR?
> 
> I don't think so, but I'm inclined to say don't look for /tmp.  That is, rely on the environment as the sole means to find the correct directory and if that is deficient, declare an error.

I agree it's not a good idea to look for a fixed path. I don't have 
broad enough UNIX systems experience to make the call on whether to look 
for additional environment variables. If TMPDIR *is* the POSIX standard 
should that be all that we support?

>>>> - if the path does not exist should one be created?
>>> No, the application should define how to handle that, not
>>> the library.
>> agreed.
> 
> +1
> 
> An accessor should not have the side effect of creating a directory.  Leave that for higher level code.

Agreed.

Thanks, Jeff