From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20251 invoked by alias); 25 Sep 2016 17:04:38 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 21976 Received: (qmail 24979 invoked from network); 25 Sep 2016 17:04:38 -0000 X-Qmail-Scanner-Diagnostics: from forward2m.cmail.yandex.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(5.255.216.20):SA:0(0.0/5.0):. Processed in 0.597339 secs); 25 Sep 2016 17:04:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,SPF_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: kp-pav@yandex.ru X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf-ipv4.yandex.ru designates 5.255.216.20 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1474822687; bh=CYpQyKGkwWwLUkW3i4KGIvK4q+1Jl05QrJXi27Lk8bI=; h=From:To:In-Reply-To:References:Subject:Message-Id:Date; b=lUanucAQ1fnaWLv39T6oU/JXJpro+fyWWNeDCNJ4o/ePmNimizhq9HbegZ27M6ijT 8Z0qxcCFcN2YuUZfdhh8gdmj8idKBgtjdcg53Y+pwKTdrM4sFPYHSFzCRcUux40mTI QKnizbMC+Ybl3iD1RMrl3DNTK/xdiFwA2xpJnfpg= Authentication-Results: mxback8j.mail.yandex.net; dkim=pass header.i=@yandex.ru From: "Nikolay Aleksandrovich Pavlov (ZyX)" To: Bart Schaefer , Zsh Users In-Reply-To: <160924221731.ZM30342@torch.brasslantern.com> References: <4DC55226-A041-42E5-B8B1-3AB1E7E6AB53@macports.org> <1082821474761933@web24j.yandex.ru> <160924221731.ZM30342@torch.brasslantern.com> Subject: Re: Feature request: set extension for =( ) created file MIME-Version: 1.0 Message-Id: <1769091474822687@web1j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 25 Sep 2016 19:58:07 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 25.09.2016, 08:19, "Bart Schaefer" : > 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.