mktemp(1) in /tmp or $PWD?

[Alexey Shuvaev]

On Fri, Feb 26, 2010 at 01:47:11AM -0800, Garrett Cooper wrote:
> 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
>
This likely to go in the bikeshed direction, but I can see arguments
that it is expected behavior because (by typing just 'mktemp')
you haven't specified what you want to achieve.
Moreover I would say that

~> mktemp app1XXXX
app1D7yv
~> ls
app1D7yv      films_list    mbox          obj           tmp
bin           install       mc34063ti.pdf papers        to_do.tar
data          layer         meep_todo     pentomino
doc           libctl        mgtkdatabox   src
drawings      libctl.orig   mnt           svn

is also the expected behavior. I would be surprised to find app1D7yv in
/tmp/ or whatever else and not in PWD.
That being said I think nobody uses mktemp(1) from the interactive prompt.
But on this route what is wrong with explicit calls like
'mktemp /tmp/tmp.XXXXXXXX' in your shell script?
On the general note relying on the specific defaults is the best way
to seed random incompatibility into any program...

> [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.
> 
0.00$,
Alexey.