From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11827 invoked from network); 11 Feb 2009 20:13:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 11 Feb 2009 20:13:50 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 87371 invoked from network); 11 Feb 2009 20:13:47 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 11 Feb 2009 20:13:47 -0000 Received: (qmail 24878 invoked by alias); 11 Feb 2009 20:13:41 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26555 Received: (qmail 24868 invoked from network); 11 Feb 2009 20:13:41 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 11 Feb 2009 20:13:41 -0000 Received: from mail-fx0-f22.google.com (mail-fx0-f22.google.com [209.85.220.22]) by bifrost.dotsrc.org (Postfix) with ESMTP id A944A80271F0 for ; Wed, 11 Feb 2009 21:13:37 +0100 (CET) Received: by fxm3 with SMTP id 3so36423fxm.21 for ; Wed, 11 Feb 2009 12:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=CuyiG14Lxx/7VbC/ee4Fz080mNaKeytNc0xvjsDaHeQ=; b=OoPRF6HB8eVKzYHEDjg1cB9giCOjLeclCOapV7bLTbDQWrUhNWr7V2SFpu4kh9o6Wp srz2F/W493Yk3/8SzoopuCcTyBpKX9PRv2wZI6SD9JdBZb6lEMYCZgcEJB8k9KhUwxo/ r6LOC6GWxTdrMK11k64CEO6WhI3kbpafAjBxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=i+bzWk+iqiuHfEDtdxOgy0eA0q3U9F8NA6HILcLQhDDheOdyy2GJLBvzMckSCCDSlI w0yJJ138Y9v7LxXYQfbZ1bd6KGTmSdDd384Mau4k82+zasSIywWIlRT/rf7H73A+YMLt 8bq0ejWgslu3z/w4ehUe2Ca/wvHdqY2T2yU8w= MIME-Version: 1.0 Received: by 10.86.82.16 with SMTP id f16mr17862fgb.26.1234383217073; Wed, 11 Feb 2009 12:13:37 -0800 (PST) Date: Wed, 11 Feb 2009 21:13:37 +0100 Message-ID: <2d460de70902111213w2f8b9a6du921cdf1c42c32d71@mail.gmail.com> Subject: Proposed patch for options.yo (was: Re: bug in single_command) From: Richard Hartmann To: Bart Schaefer Cc: Zsh hackers list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/8980/Wed Feb 11 17:40:45 2009 on bifrost X-Virus-Status: Clean First of all, sorry for the subject of the email. I wanted to change it after I found out what the actual issue was but forgot. The body of the mail changed quite substantially. Duh.. On Wed, Feb 11, 2009 at 19:13, Bart Schaefer wrote: > I suggest changing "the command line" here to something like "in the > flags supplied at invocation of the shell" to match terminology that > is used elsewhere, e.g., the manual section "Invocation". Very good point. I'll check against the docs that my terminology is correct. > It's true that "the command line" used elsewhere in the manual often > refers to the equivalent of the ZLE input buffer. On the other hand, > it seems so obvious that "setopt single_command" would cause the shell > to immediately exit (after all, it has now executed a single command!) > that I hardly believe thsi is a source of significant confusion. Hardly significant, agreed. But when reading docs, I go into pedantic prick mode, looking for stuff to improve :p Liberal in what you require, strict in what you provide and all that. > A better question might be why these options are not mentioned in the > "Invocation" section, since that's the only context in which they make > sense, rather than being relegated to the "Single Letter Options". I'll see where that fits and work it into the patch. > Without looking, I'd suspect that the reason is that dosetopt() may at > times be called from a context where emitting an error message is not > appropriate. No idea about appropriate (did not dig too deeply), but it _is_ used without any checking of return values etc. Namely in Src/builtin.c 540 & 541: dosetopt(VERBOSE, 0, 0); dosetopt(XTRACE, 0, 0); All occurences in Src/init.c Src/options.c 506: static void setoption(HashNode hn, int value) { dosetopt(((Optname) hn)->optno, value, 0); } > In general it's bad programming to spew to the standard > error stream at too low a level because it takes control away from the > caller. Agreed, but I didn't know it's too low when I wrote this (and I don't think it's my place to decide those matters, anyway). That said, I should have checked all places it is used in before suggesting direct printing. Return values? Or passing back an actual string? Richard