Re: zsh-3.0-pre4 released

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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"