Subject: Re: [boost] [filesystem] temp_dir_path()
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-11 07:32:32
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
> 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.
> >> - 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.
> >> - if the path does not exist should one be created?
> > No, the application should define how to handle that, not
> > the library.
An accessor should not have the side effect of creating a directory. Leave that for higher level code.
Rob Stewart robert.stewart_at_[hidden]
Software Engineer, Core Software using std::disclaimer;
Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk