bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

temp file suffixes: mktemp DWIM


From: Eric Blake
Subject: temp file suffixes: mktemp DWIM
Date: Mon, 2 Nov 2009 20:39:20 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Now that glibc 2.11 has mkostemps, and I'm working on adding that to gnulib, it 
would be nice to expose the idea of an explicit suffix to temporary file 
names.  But rather than require the user to count how long their suffix is, I 
imagine it would make more sense to give mktemp(1) some do-what-I-mean smarts.  
That is, I envision:

mktemp foo-XXXXXX.txt

calling mk[o]stemps("foo-XXXXXX.txt",4,0), automatically figuring out that the 
final run of XXXXXX in the template implies a suffix of length 4, to create a 
file such as "foo-abcdef.txt".

Maybe it's even worth an option in case a user wants an explicit X in the 
suffix, as in:

mktemp --suffix-len=1 foo-XXXXXXX

to create a file named foo-abcdefX, although that starts to be a bit of 
overkill.  Meanwhile, if the user supplies less than 6 X, I think it would also 
be nice to supply the missing X rather than facing an EINVAL from too few X, as 
in:

mktemp foo-

calling mkstemp("foo-XXXXXX").  Then again, this would be a slight change from 
the current codebase, since 'mktemp foo-XXX' currently creates a file such 
as "foo-abc" rather than giving EINVAL or creating "foo-abcdef".

Finally, is there any reason that we guarantee that more than six X will be 
munged, even though glibc munges only the last six X?  In other words, since 
the default template is tmp.XXXXXXXXXX, do we want to continue to guarantee 
that we generate a file such as tmp.abcdef1234, or are we okay with generating 
tmp.XXXXabcdef?  Or do we even shorten the default template to just six X, 
since that seems to be enough to guarantee success.

Thoughts?

-- 
Eric Blake






reply via email to

[Prev in Thread] Current Thread [Next in Thread]