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

[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.

} 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
    }
  }

} 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?

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.