On Fri, Feb 26, 2010 at 01:47:11AM -0800, Garrett Cooper wrote: > On Thu, Feb 25, 2010 at 10:27 PM, Doug Barton <do...@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: > > gcoo...@orangebox ~/Downloads/susv4/susv4 $ uname -or > 2.6.31-gentoo-r6 GNU/Linux > gcoo...@orangebox ~/Downloads/susv4/susv4 $ mktemp > /tmp/tmp.5pmHxn3UfQ > gcoo...@orangebox ~/Downloads/susv4/susv4 $ mktemp -d > /tmp/tmp.Q0PZbsf9BG > > Compared with: > > [gcoo...@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... > [gcoo...@optimus ~]$ mktemp -d > usage: mktemp [-d] [-q] [-t prefix] [-u] template ... > mktemp [-d] [-q] [-u] -t prefix > [gcoo...@optimus ~]$ mktemp -d tmp.XXXXXXXXXX > tmp.cvZo2ABNRv > [gcoo...@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: > > [gcoo...@optimus ~]$ mktemp -t tmp > /tmp/tmp.vAi6eCpD > [gcoo...@optimus ~]$ mktemp -t tmp -d > /tmp/tmp.0f3Z9L5R > [gcoo...@optimus ~]$ mktemp -t tmp -t notsotmp -d > /tmp/notsotmp.MTYHIGFs > [gcoo...@optimus ~]$ mktemp -t foo.XXXXXX > /tmp/foo.XXXXXX.rGssqAZk > [gcoo...@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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
