From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 26 09:47:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10248106566C; Fri, 26 Feb 2010 09:47:17 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D38DE8FC13; Fri, 26 Feb 2010 09:47:16 +0000 (UTC) Received: by pwj7 with SMTP id 7so7169544pwj.13 for ; Fri, 26 Feb 2010 01:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Lcek5CXYxth37dUqB52SxLjN/fBiI587lzGZaBUNrZI=; b=EBQn0GaDVvx5+OeiYrrGVDpzK51jG0o41RRPR+fCUr0ZXV4GptcvyUVCs+avB6Z8KT 7+UxNAys3w7ImEUA9ONKhL3LBUTxsUpdcQkVTYlnX4m42HqlRe8/mMJdCZ7ppVmn9z0L VOEispQtbJSIk0l5ClJcmhebqKwH3ny4TqLzk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ig+nFFRfcNY8DgNFnCifyR7n3CaJUPWUx5k6NR67uTJdix6hbkLZxEmFCks6OHT0wl k+tWlghW3q8lDhj0JLqeXsnbqw0OXBV4yTSmr+lH1nLWm3KpIyQ/41ICI7A8zzcuRkLD DhveFS11yTFsTL2nTaDgenglY3qq7YzAtpggM= MIME-Version: 1.0 Received: by 10.142.195.18 with SMTP id s18mr56390wff.325.1267177631423; Fri, 26 Feb 2010 01:47:11 -0800 (PST) In-Reply-To: References: <7d6fde3d1002251850m3d32904emece0182e905b84c5@mail.gmail.com> <7d6fde3d1002252100oc64434ci5f6783ff10a9f0ea@mail.gmail.com> Date: Fri, 26 Feb 2010 01:47:11 -0800 Message-ID: <7d6fde3d1002260147h428dc97ere1722e8b658d321e@mail.gmail.com> From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-Hackers Subject: Re: mktemp(1) in /tmp or $PWD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 09:47:17 -0000 On Thu, Feb 25, 2010 at 10:27 PM, Doug Barton 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@orangebox ~/Downloads/susv4/susv4 $ uname -or 2.6.31-gentoo-r6 GNU/Linux gcooper@orangebox ~/Downloads/susv4/susv4 $ mktemp /tmp/tmp.5pmHxn3UfQ gcooper@orangebox ~/Downloads/susv4/susv4 $ mktemp -d /tmp/tmp.Q0PZbsf9BG Compared with: [gcooper@optimus ~]$ mktemp usage: mktemp [-d] [-q] [-t prefix] [-u] template ... mktemp [-d] [-q] [-u] -t prefix [gcooper@optimus ~]$ mktemp -d usage: mktemp [-d] [-q] [-t prefix] [-u] template ... mktemp [-d] [-q] [-u] -t prefix [gcooper@optimus ~]$ mktemp -d tmp.XXXXXXXXXX tmp.cvZo2ABNRv [gcooper@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@optimus ~]$ mktemp -t tmp /tmp/tmp.vAi6eCpD [gcooper@optimus ~]$ mktemp -t tmp -d /tmp/tmp.0f3Z9L5R [gcooper@optimus ~]$ mktemp -t tmp -t notsotmp -d /tmp/notsotmp.MTYHIGFs [gcooper@optimus ~]$ mktemp -t foo.XXXXXX /tmp/foo.XXXXXX.rGssqAZk [gcooper@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