mktemp(1) in /tmp or $PWD?

[Garrett Cooper]

On Thu, Feb 25, 2010 at 10:27 PM, Doug Barton <dougb at freebsd.org> wrote:
> On Thu, 25 Feb 2010, Garrett Cooper wrote:
>
>> So what I did was I wrote up a patch to be *I know... here it comes*
>> more like GNU coreutils' copy of mktemp.
>
> What's the motivation for this?

Less typing and quirks because every other command line and
programmatic implementation I've run across (Linux, perl, python) uses
a similar paradigm with these sets of APIs. Example:

gcooper at orangebox ~/Downloads/susv4/susv4 $ uname -or
2.6.31-gentoo-r6 GNU/Linux
gcooper at orangebox ~/Downloads/susv4/susv4 $ mktemp
/tmp/tmp.5pmHxn3UfQ
gcooper at orangebox ~/Downloads/susv4/susv4 $ mktemp -d
/tmp/tmp.Q0PZbsf9BG

Compared with:

[gcooper at optimus ~]$ mktemp
usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
       mktemp [-d] [-q] [-u] -t prefix
[gcooper at optimus ~]$ mktemp -d
usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
       mktemp [-d] [-q] [-u] -t prefix
[gcooper at optimus ~]$ mktemp -d tmp.XXXXXXXXXX
tmp.cvZo2ABNRv
[gcooper at optimus ~]$ mktemp tmp.XXXXXXXXXX
tmp.KFnF5zomVn

> I'm a little confused about why we'd want to change this when the -t option already exists.

Because 1) -t requires that you spell out the entire path in a more
terse way, 2) tacks on more information in a more counter intuitive
manner, and 3) can only be used once per mktemp(3) call. Example:

[gcooper at optimus ~]$ mktemp -t tmp
/tmp/tmp.vAi6eCpD
[gcooper at optimus ~]$ mktemp -t tmp -d
/tmp/tmp.0f3Z9L5R
[gcooper at optimus ~]$ mktemp -t tmp -t notsotmp -d
/tmp/notsotmp.MTYHIGFs
[gcooper at optimus ~]$ mktemp -t foo.XXXXXX
/tmp/foo.XXXXXX.rGssqAZk
[gcooper at optimus ~]$ mktemp -t /something/foo.XXXXXX
mktemp: mkstemp failed on /tmp//something/foo.XXXXXX.J3CGs9dK: No such
file or directory

> Also, does POSIX say anything about what the default should be?

Nope. No mention of mktemp(1) in either v3 or v4 of the POSIX 1003.1 specs.

FWIW, the major advantages that BSD has on the coreutil's mktemp is
that it's half the size of coreutil's mktemp; plus, you only need to
call mktemp(1) once for multiple files. I have no intent on changing
that behavior because I think it's cool and more innovative than the
dumbed down single invocation mktemp(1) setup with coreutil's mktemp.

Thanks,
-Garrett