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? If it does, I'd like to hear chapter and verse, because then, lots of software doesn't conform to this and could be fixed.
In my experience, there are actually four of these TMP, TEMP, TMPDIR and TEMPDIR. On my Debian system, I've redirected these to my homedir at ~/tmp/{tmp,temp,tmpdir,tempdir} and looking at ~/tmp I see this:
uli@fruitbox:~/tmp$ du 24K ./tmp 4.0K ./tempdir 122M ./tmpdir 24M ./temp
plus a bunch of files under /tmp bearing my ownership, probably from programs with a hard-coded path.
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_0... On Mac OSX TMPDIR refers to the users temp folder.
Questions: - should Posix return an empty path or an error when empty?
I'd say an error.
Done. See the patch attached to ticket#4742. temp_dir_path() is now consistent with the error handling of the rest of filesystem.
- should Windows provide a more 'temp-path' centric error?
I wouldn't bother. If someone needs this, they will probably file a bug ticket.
- 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?
- if the path does not exist should one be created?
No, the application should define how to handle that, not the library.
agreed. Thanks, Jeff