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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 eb5ff0da for ; Fri, 11 Oct 2019 06:46:55 +0000 (UTC) Received: (qmail 25561 invoked by alias); 11 Oct 2019 06:46:47 -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: 44814 Received: (qmail 16195 invoked by uid 1010); 11 Oct 2019 06:46:47 -0000 X-Qmail-Scanner-Diagnostics: from mail-40135.protonmail.ch 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(185.70.40.135):SA:0(-2.7/5.0):. Processed in 3.221209 secs); 11 Oct 2019 06:46:47 -0000 X-Envelope-From: jsrice@protonmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.protonmail.ch designates 185.70.40.135 as permitted sender) Date: Fri, 11 Oct 2019 06:46:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1570776367; bh=FTrtffHiS1rC/Az8MGUehaaB55T1ieYfH3LIPtc9MX8=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=BsSJz3QrTc24YBKW21vMCiq6+2YYS2FiU7cB6lfiPTOQL14YXSIYbNWO2gsLZ+C5R Bhg1zKRxEnK/N0zBOL57i8/RtHvqiaDaPVoqg9chG66tWRqb6XcA/ojoV68huPcYJ8 Ikm0K5JGVdDFosfqIGN9A8bJHijqccPrJyQdL51g= To: "zsh-workers@zsh.org" From: Joe Rice Reply-To: Joe Rice Subject: Re: [PATCH] respect nullglob given multios Message-ID: In-Reply-To: <8915ded7b3350db47105804659b99b2c3e07cf45.camel@fifi.org> References: <1570725646.5885.4.camel@samsung.com> <8915ded7b3350db47105804659b99b2c3e07cf45.camel@fifi.org> Feedback-ID: zuUmUIiSanTclByPD4QM8577gj-MNEd1LLupye9O0Jn3hx3VaqOEMvk-3tX9osjU9S2JAO0ka4_drqQM-SjB3g==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > 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 prop= osition, and if they were using an explicit qualifier, then I think they wo= uld have sufficiently acknowledged that behavior. Clear acknowledgement of behavior: % setopt nullglob ... few lines ... % expensive > * % expensive > *(N) Concerning unexpected behavior: % setopt nullglob ... many lines ... % expensive > * This can be addressed explicitly by toggling nullglob off on this line with= (N). > 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 I think these three are very different in the user's mind: % print * Should list the files in the current directory. % print Should print only a newline, which happens to be the same output as listing= an empty directory. % print > * Should truncate and write a single newline to each file in the current dire= ctory. The only difference this patch makes is that the latter now writes "to noth= ing" when the nullglob is enabled. > % print > > zsh: parse error near `\n' > > I'd argue that the behavior should be the same: both should send to > /dev/null or not. I think this is the most different, as multios doesn't have a conceptual ef= fect on normal use of single redirections. Redirections are conceptually (#= )(<|>)(target) anywhere on the line so changing behavior on multios seems o= dd. Consider this case: % > * grep ... '>' is not pulling the next resolved tokens and testing if that is empty. I= t's pulling the pattern and testing if that is resolves as empty. % print > Offers no such pattern. > 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? That is expected with the current implementation (5.7.1), this patch would = intentionally resolve it as `print > /dev/null` instead. Another bit that seems relevant is how this patch handles brace expansion u= nder multios: % setopt nomultios % empty=3D() % print > ${^empty} zsh: no such file or directory: % setopt multios % print > ${^empty} Which is desirable (I think). % ls foo.a % grep < *.{a,b,c}(N) Resolves as: % grep < {*.a(N),*.b(N),*.c(N)} % grep < foo.a < /dev/null < /dev/null Which should be functionally the same and seems to fit in with how brace ex= pansion and patterns interact. Joe