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.0 required=5.0 tests=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 ca045ec3 for ; Fri, 11 Oct 2019 00:26:19 +0000 (UTC) Received: (qmail 22247 invoked by alias); 11 Oct 2019 00:26:09 -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: 44813 Received: (qmail 18051 invoked by uid 1010); 11 Oct 2019 00:26:09 -0000 X-Qmail-Scanner-Diagnostics: from granite.fifsource.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25594. spamassassin: 3.4.2. Clear:RC:0(173.255.216.206):SA:0(-1.9/5.0):. Processed in 2.463175 secs); 11 Oct 2019 00:26:09 -0000 X-Envelope-From: phil@fifi.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at fifi.org designates 173.255.216.206 as permitted sender) Message-ID: <8915ded7b3350db47105804659b99b2c3e07cf45.camel@fifi.org> Subject: Re: [PATCH] respect nullglob given multios From: Philippe Troin To: "zsh-workers@zsh.org" Date: Thu, 10 Oct 2019 17:25:32 -0700 In-Reply-To: <1570725646.5885.4.camel@samsung.com> References: <1570725646.5885.4.camel@samsung.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit On Thu, 2019-10-10 at 16:40 +0000, Peter Stephenson wrote: > On Thu, 2019-10-10 at 01:18 +0000, Joe Rice wrote: > > This patch makes multios behave less surprisingly with nullglob. > > > > Currently, multios throws a file not found error when a nullglob is > > given. This patch inserts /dev/null into the redirection list when > > the > > glob returns empty with no errors. > > > > Is this a behavior that would interest anyone else? I find myself > > using the `cat /dev/null *(N.)` idiom quite a bit and I thought the > > behavior made sense for the null case in multios. > > This does seem a logical effect, though it ought to be documented. I am not sure if it's that logical. What about if the pipeline on left of the redirection is something expensive? I'd rather have the command fail than starting a long-running job whose output will be lost. Also, conceptually, this introduces a difference between the behaviors of an explicitly empty redirection and an empty redirection after filename expansion. Compare: % zsh -f % echo $ZSH_VERSION 5.7.1 % print nosuchfileprefix*(N) % print % print > nosuchfileprefix*(N) # Implicitly sends to /dev/null % print > zsh: parse error near `\n' % I'd argue that the behavior should be the same: both should send to /dev/null or not. Incidentally, and as a completely separate issue, on an unpatched 5.7.1 zsh (Fedora 30 stock package), the command above succeeds and creates a file: % print > nosuchfileprefix*(N) % ls nosuchfileprefix*(N) 'nosuchfileprefix'$'\207\210''N'$'\212' Is that expected? Phil.