Re: [RFC] adding zmktemp command

[Clinton Bunch <cdb_zsh@zentaur.org>]

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