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 FAA22146 for ; Sun, 28 Jul 1996 05:47:16 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id PAA25160; Sat, 27 Jul 1996 15:25:27 -0400 (EDT) Resent-Date: Sat, 27 Jul 1996 15:25:27 -0400 (EDT) From: "Bart Schaefer" Message-Id: <960727122628.ZM26296@candle.brasslantern.com> Date: Sat, 27 Jul 1996 12:26:28 -0700 In-Reply-To: Zefram "Re: zsh-3.0-pre4 released" (Jul 27, 6:03pm) References: <2259.199607271703@stone.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: hzoli@cs.elte.hu, zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"T8S0V1.0.296.dqc-n"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1793 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jul 27, 6:03pm, Zefram wrote: } Subject: Re: zsh-3.0-pre4 released } } >Actually, I'd say the biggest change is "setopt nofoo" == "unsetopt foo". } >Which I still think should have been left out until some post-3.0 version. } } Why? It breaks nothing except for scripts that try to detect options } being set by doing `setopt | grep foo`, which is broken anyway. It also breaks the setopt/unsetopt wrapper functions I sent a few days ago, but I don't consider that important. 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. 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? Why shouldn't "nohup" parallel the command prefix of the same name? Even BEEP is a bit vexing. At least with the NO_ prefix, you could tell that there is some expected behavior that is being modified. It's my opinion that, with the exception of options that reflect shell state (such as "interactive" and "shinstdin"), the baseline expected behavior of the shell should be the behavior with all options UNset. That's why they're called "options" after all; because they introduce optional behavior, different from the baseline. Please note that I don't object much to the "setopt no..." == "unsetopt" behavior. It's the renaming of a number of the NO_ options that bothers me. I'd be perfectly happy to have "setopt NO_NO_RCS" be a valid way to "unsetopt NO_RCS", but I don't want to "setopt RCS", and I don't like to have "rcs" showing up in my setopt output. 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. ("What does the Revision Control System have to do with my init files?") } The general idea is that we have a list of fixed option `aliases', } which provide alternative names for certain options. The list itself } would look something like } } {"ignorebraces", -BRACES}, } {"trackall", HASHCMDS}, } } The "trackall" entry provides a ksh name for the equivalent zsh } option. The "ignorebraces" entry provides backward compatibility, in } the hypothetical situation that we decide that "braces" is a better } name. I wouldn't make that type of change when adding the mechanism, } but would only do some ksh compatibility names. Now THIS I could support, because it would permit us to rename some of the options without losing backwards compatibility and without having to invert their default boolean sense. I'd vote for renaming at least these six: braceccl (what's a CCL, anyway?) histnostore nobadpattern nobanghist norcs (IGNORE_RC_FILES, perhaps?) nounset (NULL_UNSET, ala NULL_GLOB?) -- 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"