On Wed, Oct 13, 2010 at 7:03 PM, Jeff Flinn <TriumphSprint2000@hotmail.com> wrote:
John B. Turpish wrote:
On Tue, Oct 12, 2010 at 8:49 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
John B. Turpish wrote:
'directory.in.output' provided me with nothing. So I do not know where it got the directory for tmpnam(), but not from any env var.
According to <http://linux.die.net/man/3/tmpnam>, one should not use tmpname(3) but should instead call mkstemp(3) or tmpfile(3). The former makes a unique filename from a supplied template, so it is the caller's responsibility to select the directory. The latter creates a file which is deleted automatically when closed or when the process terminates. Neither mentions e-vars as influencing their behavior.
What I was getting at is there's already a function in the standard C library that needs to determine where to put temporary files - and in my mind that would be what the temporary directory is - and its result disagrees with what's being discussed here. mkstemp() doesn't have to come up with directory itself - as you pointed out. tmpfile() would, but printing the result of the decision not as convenient for a simple test as with tmpnam(). Besides, if the use case (not positive what it is, actually) was covered by tmpfile() then there would be no need for the function being discussed.
My primary use cases are in interacting with legacy 3rd party apps that read/write from/to the users temp directory with advertised file names, and an historical place to direct users if they want to see intermediate level logged data.
I get the temporary directory in Windows to create zip files in. These get added to an email as attachments. The files need to have well-known names formed by the application. I'm just interested in a writable place they can be created in and then soon deleted. Regards, Pete