From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7617 invoked by alias); 13 Aug 2015 08:32:50 -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: X-Seq: 36145 Received: (qmail 29897 invoked from network); 13 Aug 2015 08:32:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f5-f794b6d000001495-1f-55cc5628369b Date: Thu, 13 Aug 2015 09:32:38 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: PRINT_EXIT_VALUE: Suppress for if/while conditions Message-id: <20150813093238.046a1b08@pwslap01u.europe.root.pri> In-reply-to: <20150731231225.GB2054@tarsus.local2> References: <20150731231225.GB2054@tarsus.local2> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsVy+t/xa7oaYWdCDQ61GVgcbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujM4ld1gKVgtW/N52mL2B8TxvFyMnh4SAicS/v7vYIWwxiQv3 1rN1MXJxCAksZZToWH0TypnBJLG0/yszSJWQwDZGieaHySA2i4CqxLJF75lAbDYBQ4mpm2Yz gtgiAuISZ9eeZwGxhQXsJfrPbmcDsXmB7O5fjawgNqeAkcTJSyugZhpKfH11GizOL6AvcfXv JyaIi+wlZl45wwjRKyjxY/I9sJnMAloSm7c1sULY8hKb17yFmqMucePubvYJjEKzkLTMQtIy C0nLAkbmVYyiqaXJBcVJ6blGesWJucWleel6yfm5mxghQft1B+PSY1aHGAU4GJV4eDc8Oh0q xJpYVlyZe4hRgoNZSYT3qNyZUCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8M3e9DxESSE8sSc1O TS1ILYLJMnFwSjUw7vPKF63ZbhjFJWy22n6xMIvvdLNn9TdvGl10ma508fiOf+23J32V2FSu eKR05Tceo+4gy1n77bTq48s9n5t8cEi9JuvTx/Yv5oxS3qVp2w8zxh39e/PLwzuml3XCzh5j MjeP9//2/rWfgUD/jtKA1c6/r33M70+4tZkp1Mm84v3Nx2L5npOnK7EUZyQaajEXFScCAMYG H+1WAgAA On Fri, 31 Jul 2015 23:12:25 +0000 Daniel Shahaf wrote: > I'd like to disable the effect of PRINT_EXIT_VALUE while evaluating > if/while conditions, since it's uninformative (conditions sometimes > fail, that's their sine qua non) and annoying (when doing a for/if > interactively and the 'if' condition is false in many iterations, the > option must be disabled to prevent stderr spamming). > > So far I've got it working for builtins ("if false ; then : ; fi" > doesn't warn, whereas in git tip it does), but not for external commands > (with the patch, "if =false ; then : ; fi" still warns, but I'd like it > not to warn). This is related to the MONITOR option: > > % if =false ; then : ; fi > zsh: exit 1 =false > % unsetopt monitor > % if =false ; then : ; fi > % > > I'm guessing that has something to do with printjob(), since it checks > both 'jobbing' and opts[PRINTEXITVALUE], but I don't understand that > function. Could I get a hint, please? It's a bit mysterious quite why it's implemented like that --- you might have thought something parallel to ERREXIT would make more sense --- but I don'e think what it actually does is that mysterious. Bascially, handling of printing exitvalues is divided into two parts: for anything that runs within the shell it's done immediately the command is run; for anything else it runs in printjob() when the job status changes (with the side effect of dependence on MONITOR). It might be done this way to handle background jobs, which wouldn't be picked up if you did it in a way more naturally related to the execution hierarchy. But the intention is clearly that these are otherwise parallel cases. So I think anything you do in the one case you can do in the other, as you're proposing, up to asynchronous effects. > Would it be correct to just slip a "&& !printexitvalue_depth" to the "if > isset(PRINTEXITVALUE)" checks in printjob()? I am not sure that would > be correct in the synch=0 case. Yes, I think you probably need something like (!printexitvalue_depth && sync == 1) since the cases of calling it from jobs or bg or fg are irrelevant. pws