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 GAA22622 for ; Sun, 28 Jul 1996 06:20:43 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id QAA25705; Sat, 27 Jul 1996 16:03:50 -0400 (EDT) Resent-Date: Sat, 27 Jul 1996 16:03:50 -0400 (EDT) From: Zefram Message-Id: <841.199607272002@wabe.dcs.warwick.ac.uk> Subject: Re: zsh-3.0-pre4 released To: schaefer@nbn.com Date: Sat, 27 Jul 1996 21:02:38 +0100 (BST) Cc: A.Main@dcs.warwick.ac.uk, hzoli@cs.elte.hu, zsh-workers@math.gatech.edu In-Reply-To: <960727122628.ZM26296@candle.brasslantern.com> from "Bart Schaefer" at Jul 27, 96 12:26:28 pm X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]7874.17 X-US-Congress: Moronic fuckers MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"xEmYG1.0.WH6.bOd-n"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1794 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu >What I do consider important is the confusion from the introduction of a >large number of new options -- which is what it looks like to anyone who >simply glances at the output of "setopt"; and which it is, syntactically >at least, although less so semantically. 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. 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).) >Further, although I'm extremely happy about the attention that was paid >to backwards compatibility, I can only repeat how uncomfortable I am >about options that end up named BAD_PATTERN, EQUALS, EXEC, HUP, RCS, and >UNSET. What does "setopt unset" look like to you? Confusing. However, I do prefer unset(UNSET) to isset(NOUNSET). > Why shouldn't "nohup" >parallel the command prefix of the same name? It does. >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. Not to mention that not even all the non-special options defaulted to off anyway, IIRC. >BTW, while I'm on the subject, I'd like to throw in my vote for changing >SH_FILE_EXPN to KSH_FILE_EXPANSION. Besides being, as Zefram pointed out, >more a ksh than sh thing, spelling out the "expansion" is no longer than >ALWAYS_LAST_PROMPT, and I think we should avoid unnecessary abbreviations. Partially agreed. When I produced that patch I used SH_FILE_SUBST, in order to avoid excessive length but also avoid a cryptic abbreviation; I guess a full "expansion" is fine. But whether it's sh or ksh makes little difference, as both behave the same way in this regard. >("What does the Revision Control System have to do with my init files?") That one had me stumped for a while. >braceccl (what's a CCL, anyway?) Character CLass? I think this one needs changing; how about BRACE_CHARS? Does anyone have a better idea? >histnostore Should be HIST_STORE. >nobadpattern BAD_PATTERN currently means "complain about malformed patterns". I can't immediately come up with a better name. >nobanghist Again, I don't see a better name. There's history regardless of this option -- it only enables the bangchar form. (Admittedly not always a !, but how else can one describe this?) >norcs (IGNORE_RC_FILES, perhaps?) RC_FILES, meaning what RCS currently does. >nounset (NULL_UNSET, ala NULL_GLOB?) Yes, NULL_UNSET is much clearer. Currently we have UNSET meaning "complain about unset parameters", and its negation isn't exactly obvious. Other possibilities: EXTENDED_GLOB should be ZSH_GLOB; RM_STAR_SILENT should be negated to RM_STAR_WARNING (note that changing the default behaviour is a separate issue); SHIN_STDIN should be STDIN or something less cryptic; HIST_ALLOW_CLOBBER should be HIST_ADD_CLOBBER (that's what it does); IGNORE_BRACES has already been discussed; NOMATCH should be clearer; RC_EXPAND_PARAM arguably should be RC_ARRAYS; REC_EXACT should be RECOGNISE_EXACT or ACCEPT_EXACT_MATCH or similar. -zefram