Re: Feature request: set extension for =( ) created file

["Nikolay Aleksandrovich Pavlov (ZyX)" <kp-pav@yandex.ru>]

25.09.2016, 08:19, "Bart Schaefer" <schaefer@brasslantern.com>:
> On Sep 25, 3:05am, Nikolay Aleksandrovich Pavlov (ZyX) wrote:
> }
> } I would consider another thing: while extensions are significant part
> } of the file names, sometimes complete last path component or the whole
> } path matters. I would suggest that if syntax is extended to allow
> } controlling some properties of a temporary file name it should allow
> } to control everything:
>
> One thing that has to be considered is the security aspects of temporary
> file creation. Files created with =(...) have unpredictable names for
> a reason: A malicious actor should not be able to create such a file in
> advance, because if that's possible then the shell can be caused to read
> and/or write anywhere that the malicious actor desires.
>
> We even swept through the completion shell-functions not long ago and
> revised them all to create their temporary files using =(...) and then
> hardlink them with the actual desired file names. The linked files
> are then removed before functions exit, via an "always" block.

If user explicitly requested temporary file at `/home/foo/bar` then he is not satisfied with usual `=()` location and thus simply will use other options in place of `=()`. Providing extension to a `=()` syntax which allows specifying whole name should not open any security holes because it is not the default and it is a replacement for less convenient alternatives (i.e. `always` block). Specifying part of the name (extension or trailing path component) as I suggested is not different from the current situation: in both cases it simply adds a known suffix to a random name.

>
> } 1. Provide just an extension: use names like `/tmp/zshUkxFmK.ext`.
> } 2. Optionally provide full file name: use names like
> } `/tmp/zshUkxFmK/name.ext`, in this case temporary directory is generated and
> } then recursively deleted.
> } 3. Provide full path: allow generating automatically removed temporary files
> } at any selected location.
> } 4. Optionally make this feature generate temporary directories and not files,
> } if code for 2. is written this should be easy.
>
> The "mktemp" utility is designed to cover nearly all of these cases,
> and I don't know of any likely situation in which use of an "always"
> block (see next example) would leave something behind that the use
> of =(...) wouild not also leave behind.
>
>   () {
>     {
>       local tempdir=$(mktemp -d)
>       # ... do stuff in $tempdir ...
>     } always {
>       [[ -n $tempdir ]] && /bin/rm -r $tempdir
>     }
>   }

This is an argument against `=()` as a whole, not against my proposal. I can use `mktemp`+`always` block everywhere I use `=()`, but yet `=()` exists.

>
> } The key point is that I sometimes need temporary file in a specific
> } location, but I almost never needed temporary file with a specific
> } extension.
> [...]
> } As an implementation detail I would expect zsh to run parameter
> } expansion, filename expansion and filename generation and match the
> } result according to the above patterns.
>
> You can combine mktemp and zsh temp files, too:
>
>     local tempdir=$(mktemp -d -p /*/${specific}/location)
>     local TMPPREFIX=$tempdir/zsh
>     ln =(<<<'this is a silly example') $tempdir/sillyexample.txt
>     ls -l $tempdir
>
> In short it's pretty unlikely that we're going to re-implement mktemp
> by inventing convoluted variations of =(...) syntax.
>
> Futhermore, the definition of =(...) is that the contents of the
> resulting file are the standard output of the command inside the
> parens. What would that mean in the case of a directory?

This is why I suggested to allow only empty command if one needs a directory.

>
> What might be more reasonable is to add $TMPSUFFIX, which unlike
> $TMPPREFIX would not have a value by default, and when it is set,
> append that to the temporary name.
>
> However, neither that nor any of your suggestions would accomplish
> altering the filename based on the file content. The file has to be
> created in the parent shell before the command is even run, so that
> it can be opened as the command's output; and I would not advocate
> having the shell peering at the content without being explicitly
> scripted to do so.

This feature is not what OP requested.