From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 2f7cf62e for ; Thu, 28 Mar 2019 21:14:46 +0000 (UTC) Received: (qmail 14588 invoked by alias); 28 Mar 2019 21:14:35 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44196 Received: (qmail 5026 invoked by uid 1010); 28 Mar 2019 21:14:35 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.1/25398. spamassassin: 3.4.2. Clear:RC:0(66.111.4.25):SA:0(-2.6/5.0):. Processed in 0.897882 secs); 28 Mar 2019 21:14:35 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:subject:message-id:references :mime-version:content-type:content-transfer-encoding :in-reply-to; s=fm2; bh=029OSj9mhnxKeyHnBq1LVyMic9pkUut15lETbPFg Tq0=; b=lWGbsWzlpxkp5wol/wQe4MJxLNipHbrlnE3cDaCv2uUV36xR+8sOQzSI ffSCC+B+fUY/3eVneZB5FgUxklaari7Mv0cnuFd1+qB8r8UA8BG8qh3LXPMCtXdN +An5YPs53UKzKy++SD13J4Br7mIrtId16Ch06hPCk+Qi28UEWMt2NmbmaBMkn4eT 7ujzw9/9hiCVJTGA79wpiNteKu3vucXOEVW9R+FATAodjnle4bQTjuxnsxWdWycc QV36/13rPkx/hyLKxrJYrIicDKF9s5CV1Cpa1LdnUUXm12IaUYfit+yvip3tV2NM vLU6Xj7R6i6GS1FAswFjds+JTIjRtw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=029OSj9mhnxKeyHnBq1LVyMic9pkUut15lETbPFgT q0=; b=pAnr7jGPQEKpeSoeBrJ7oHzZuOxSHih6SJhThaw2zDM98oFICYA9Vg2Ye JNmlbZJseUqzawpNDB2vI76J1FpLnT1+Jv6zT1uTsZAe5Wv6JXdG+BPeEhjEbuu+ SoStoj3Kp20rrvtknYk3XsjGiB6tpYvXFstHxhpI0o5u2K+HKHwqy/XEwd9Dgail p/sGNTm4St9j+x42DPr6rZIW5/y4IUYlulWWR7xe9YL2Nqq7wF5BthpwNqvUc8FE i+fCEQfHNNFCTlxljpHRg8Y4LeiGhCrJ4z5SFYoJLVOT2+GPywRNSMAQOIR+pKSP hApfw+EeepR1WjW6cqX+E5TT5uJRQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkeeggddugeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjfgesth ektddttderudenucfhrhhomhepffgrnhhivghlucfuhhgrhhgrfhcuoegurdhssegurghn ihgvlhdrshhhrghhrghfrdhnrghmvgeqnecukfhppeejledrudektddrheehrdeileenuc frrghrrghmpehmrghilhhfrhhomhepugdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgr mhgvnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Date: Thu, 28 Mar 2019 21:13:59 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: [RFC] adding zmktemp command Message-ID: <20190328211359.prb6pdpidcgq5xn6@tarpaulin.shahaf.local2> References: <38c2ebfc-f238-4f85-af76-b87c9e7f4531@www.fastmail.com> <45a86a2c-c277-c29e-2c69-06eec33b627a@zentaur.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45a86a2c-c277-c29e-2c69-06eec33b627a@zentaur.org> User-Agent: NeoMutt/20170113 (1.7.2) Clinton Bunch wrote on Thu, Mar 28, 2019 at 10:00:24 -0500: > On 3/28/2019 4:38 AM, Daniel Shahaf wrote: > > Clinton Bunch wrote on Wed, 27 Mar 2019 21:18 +00:00: > > > I'm thinking of adding a zmktemp command either in a new module (e.g. > > > zsh/tempfile) or in the zsh/files module. > > ... > > > Thoughts? > > A few. > > > > - I wonder if implementing mktemp in the shell is easier than expecting > > people to install a third-party mktemp(1) binary with whatever > > functionality they desire. BSD systems often have both BSD make and > > GNU make, so it's conceivable that HP-UX systems could have both the > > native mktemp(1) and a third-party one. > > (To be clear, I do not object to your RFC; I just wonder if there's a > > better solution to the underlying problem.) > > That situation is why I proposed this.  On my HP-UX systems I use gnu > coreutils mktemp, but either I have to order my path so that it's before > /usr/bin, which can get me non-standard versions of standard commands which > might affect the script, You neglected to explain why none of the other possible solutions to this subproblem is suitable for you. (For starters, there are 'add a directory to the front of $PATH that contains just GNU mktemp and nothing else' and 'use the "hash" builtin to specify a different mktemp than the one in $PATH'.) > or name it something else (which I did, gmktemp).  > Either way this makes for less portable scripts. So your problem statement is "HP-UX and Linux use incompatible mktemp(1) binaries". I don't understand why that should be fixed in zsh; shouldn't that be fixed by getting HP-UX to improve their mktemp? Compare how there is any number of instances in the FreeBSD man pages of option flags that have been added for compatibility with coreutils (see ls(1) and find(1) for example). (By the way: I wonder if mktemp(1) will be added to POSIX?) As to your proposal itself, I initially thought you were proposing to implement a drop-in replacement of some mktemp(1) out there (probably GNU's, though for license reasons it'd be easier to crib BSD's); however, reading your responses to Peter and Oliver I see that you might be thinking of adding an *idiomatic* make-temporary-files interface, e.g., one that returns an fd and/or returns the filename in REPLY to save a fork. Which is it? Could you sketch the API that will be provided to script authors? Is it "see GNU coreutils' mktemp(1) man page, plus the -f option to return an fd"? > That also requires that > the script writer have access to install packages or the wherewithal to > build these packages and install them in their home directory themselves. By this argument, we should ship an rsync implementation in zsh if HP-UX doesn't happen to ship rsync in part of its (HP-UX's) default installation. > > - O_EXCL is exposed by zsh/system's 'sysopen' builtin, so a pure zsh > > implementation should be possible. > > I didn't think about a pure zsh implementation, but modifying the template > character by character in zsh sounds like at least as much work as it is in > C, but slower. Given that there's going to be a syscall at the end anyway [open(O_EXCL)], I'm not sure if the overhead of zsh over pure C would be noticeable. I mentioned a pure zsh implementation because it could be implemented as an autoloaded function and released as a plugin (rather than a module), so it would be installable by users who don't or can't compile their own zsh, and it would even be compatible with existing zsh binaries out there. Cheers, Daniel