From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id GAA22902 for ; Sun, 28 Jul 1996 06:53:42 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id QAA25959; Sat, 27 Jul 1996 16:37:32 -0400 (EDT) Resent-Date: Sat, 27 Jul 1996 16:37:32 -0400 (EDT) From: "Bart Schaefer" Message-Id: <960727133834.ZM26853@candle.brasslantern.com> Date: Sat, 27 Jul 1996 13:38:34 -0700 In-Reply-To: Zefram "Re: zsh-3.0-pre4 released" (Jul 27, 9:02pm) References: <841.199607272002@wabe.dcs.warwick.ac.uk> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.702 02jul96) To: Zefram Subject: Re: zsh-3.0-pre4 released Cc: zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"-tFBU.0.XL6.Cud-n"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1795 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jul 27, 9:02pm, Zefram wrote: } Subject: Re: zsh-3.0-pre4 released } } I've been using the `new options' (slightly) longer than anyone else } (how's that for brag value :-)), and while I agree that it is initially } a little disconcerting, I find that I prefer the cleaner setopt output. Cleaner? Like I said, the baseline behavior should be what happens when all the options are unset. The cleanest output is none at all. } I also find that the testing of options is a little clearer in } general, in the code. (The option patch actually normalised all option } tests to either isset(FOO) or unset(FOO).) } } I do prefer unset(UNSET) to isset(NOUNSET). There's nothing that requires us to use NOUNSET in the code. You yourself used EXECOPT instead of EXEC, for example (and for obvious reasons). } > Why shouldn't "nohup" } >parallel the command prefix of the same name? } } It does. "setopt nohup" parallels it, but the output of "setopt" doesn't say "nohup". } >At least with the NO_ prefix, you could tell that there is some expected } >behavior that is being modified. } } True, that's how the options used to work, but what is the "expected } behaviour"? It varies depending on whether we're emulating sh, ksh, } csh, zsh, (when we get round to it) POSIX, or whatever. The "expected behavior" is what you get when you run "./zsh" out of the build directory on a machine that's never had zsh near it before. Emulations are just that; they're by definition not baseline behavior (unless what you're writing is nothing more than an emulator). ] Not to mention } that not even all the non-special options defaulted to off anyway The only ones that didn't are FUNCTION_ARGZERO, which is new; BG_NICE, which has always annoyed me anyway (and which originally didn't default that way, if I recall correctly); and the three HASH options, which don't change any user-visible behavior, only performance tradeoffs. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern New male in /home/schaefer: >N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday"