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 cb32f6f7 for ; Thu, 28 Mar 2019 15:03:09 +0000 (UTC) Received: (qmail 13746 invoked by alias); 28 Mar 2019 15:02:55 -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: 44190 Received: (qmail 5295 invoked by uid 1010); 28 Mar 2019 15:02:54 -0000 X-Qmail-Scanner-Diagnostics: from heimdall.zentaur.org 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(45.56.127.49):SA:0(-2.0/5.0):. Processed in 5.55745 secs); 28 Mar 2019 15:02:54 -0000 X-Envelope-From: cdb_zsh@zentaur.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at zentaur.org designates 45.56.127.49 as permitted sender) DKIM-Filter: OpenDKIM Filter v2.11.0 heimdall.zentaur.org x2SF1x8m013836 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zentaur.org; s=default; t=1553785326; bh=D6NpQwiDsqfpfjdc2NKEJwh/T6H8at/YtWRXyzvSjUA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=OD0BpCjzLhUqWWG+hIJVVITavfvriRcLJJuAjtSAXfBZZbrVFdb/IFqvvQBWZzvu+ FodRyiLBaCZdduNKMpsuiAwLx8/ViAcv1CYASKK+8C3wjJXkR6B502fnP3rPDQDlT4 qLwG1n+z401m3Mr+DeAoXT2DvhSl7177zN1Ny+lc= Subject: Re: [RFC] adding zmktemp command To: Daniel Shahaf , zsh-workers@zsh.org References: <38c2ebfc-f238-4f85-af76-b87c9e7f4531@www.fastmail.com> From: Clinton Bunch Message-ID: <45a86a2c-c277-c29e-2c69-06eec33b627a@zentaur.org> Date: Thu, 28 Mar 2019 10:00:24 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <38c2ebfc-f238-4f85-af76-b87c9e7f4531@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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, or name it something else (which I did, gmktemp).  Either way this makes for less portable scripts.  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. > > - There's already a gettempname() function in the shell's C implementation; > it relies on mktemp(3) being available. A module implementation might > be able to reuse that. Actually I was thinking about modifying this as well to use either a system mkstemps where available or a hand-rolled one.  The names generated on HP-UX by mktemp(3) are extremely predictable (basically it zero-pads the pid and starts incrementing the leftmost digit on subsequent calls.  This is likely to be a bigger deal in a shell script where the tempfile might be repeatedly opened and closed and the name handed off as an argument to an external command, than internally where all I/O to the file is done with an already opened file descriptor. > > - 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. > > (I think you're aware of the following, but for the record:) > > There is a *limited* workaround: '() { … } =(:)' creates a tempfile (in > ${TMPPREFIX:h}, if that's set). The catch is that the file is deleted > when the anonymous function returns, so it's effectively a lexically > scoped tempfile. And, of course, it's not a substitute for «mktemp -d». > (So, no, that's not a replacement to a proper mktemp(1).) > > Cheers, > > Daniel