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=2.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_SBL_CSS autolearn=no 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 97c8451b for ; Fri, 11 Oct 2019 08:34:11 +0000 (UTC) Received: (qmail 17580 invoked by alias); 11 Oct 2019 08:34:06 -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: 44817 Received: (qmail 10254 invoked by uid 1010); 11 Oct 2019 08:34:06 -0000 X-Qmail-Scanner-Diagnostics: from smtpq1.tb.ukmail.iss.as9143.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.0/25598. spamassassin: 3.4.2. Clear:RC:0(212.54.57.96):SA:0(0.6/5.0):. Processed in 3.10118 secs); 11 Oct 2019 08:34:06 -0000 X-Envelope-From: p.w.stephenson@ntlworld.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _mailcloud.virginmedia.com designates 212.54.57.96 as permitted sender) X-Env-Mailfrom: p.w.stephenson@ntlworld.com X-Env-Rcptto: zsh-workers@zsh.org X-SourceIP: 172.25.160.142 X-CNFS-Analysis: v=2.3 cv=R8l95uZX c=1 sm=1 tr=0 a=SbParRoiaCP7T9pO5d2WBA==:117 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=gOSvBUeqVWgA:10 a=IkcTkHD0fZMA:10 a=Q79uFLovbU4A:10 a=sfOm8-O8AAAA:8 a=5nqtEaqp4PEbUc1GGrYA:9 a=QEXdDO2ut3YA:10 a=TvTJqdcANYtsRzA46cdi:22 X-Authenticated-Sender: p.w.stephenson@ntlworld.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ntlworld.com; s=meg.feb2017; t=1570782806; bh=THwM4zjf0LiEmmdpme9PTGgJIXHCJALPgDK40xhABtU=; h=Date:From:To:In-Reply-To:References:Subject; b=CiEDhZGSiQAElfV9H1l0OxBYk4lbXn2yV+pTOywXaXf5cJFa4bqyniOlRHjuatuv+ z6JMV6JBs8R5vu8+wkUnx1tDq5smtSMibAomZ3W/jlF8pxB1N5fbinU5ui5jBpqOO7 8HWTzuQZmPDoEqHbmSmBAPwIT6zo3oN13yYpTtUA5eTWBTtTzAVUPtg/RrqPHbNd71 METnP2sIQLMNoBnhF16TxcgnQhqgaEfMSfntiH2iWimUHuvHEFaUheteMsHrZWA+gv z/BzCoorDBNqGLZ9VcPVeRlhintUebm6HlzF4xJUoPSAmx8QRkJtVHk/84PrkpTdMz gQx/FGRq6USGA== Date: Fri, 11 Oct 2019 09:33:26 +0100 (BST) From: Peter Stephenson To: Joe Rice , zsh-workers@zsh.org Message-ID: <1570087298.4348177.1570782806538@mail2.virginmedia.com> In-Reply-To: References: <1570725646.5885.4.camel@samsung.com> <8915ded7b3350db47105804659b99b2c3e07cf45.camel@fifi.org> Subject: Re: [PATCH] respect nullglob given multios MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.8.4-Rev51 X-Originating-IP: 165.225.81.116 X-Originating-Client: open-xchange-appsuite X-CMAE-Envelope: MS4wfHiBX4d+rX+CPe+Xhu20eH3B456gHno4S2mi7+VrlmAzaAsefiQHiqNSGdWia9o+XlhXE3fkTdc/Tqq1sv+zQjq67z84djR1K2iLPrw2m6CSlbT/vt2S 9P7wC2feRaCd9FCRncxsa0PyXQiCpa3UbL+c+riyCiWmumK2Ss86grJan55bVAIk8uGGQ2EsFbS5OvepEPknuPKtMaKEWddjqXuRxPvUsTtFyO7HLsbFx0Xe CihzP800FeYgOdz6+OSGng== > On 11 October 2019 at 07:46 Joe Rice wrote: > > 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. > > For the case of expensive pipelines on the left side, running with a global nullglob > and expecting it to never be null already seems like a risky proposition, and if they > were using an explicit qualifier, then I think they would have sufficiently acknowledged > that behavior. I tend to agree with your analysis here. Philippe's argument seems to boil down to that nullglob should somehow behave like not having nullglob in case you don't want nullglob behaviour? But maybe others have views. pws