Re: setopt

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 30, 12:10pm, Ray Andrews wrote:
}
} I discover 'setopt -ksh_option_print', which makes " $ setopt " (by
} itself) actually useful. Shouldn't that be the default?

It is the way it is because of preserving historic behavior.  Back in
1995 or so there was briefly a push to turn zsh into a ksh clone.  As
part of that effort the collection of setopt strings was "sanitized"
so that (except for "nomatch") they all have positive sense, so that
attaching a "no" prefix is the same as using "unsetopt".  (This was
also when "junkie" got stuck into the names of some csh compatibility
options, a tidbit which annoys me to this day.)

The problem with this change was that it caused a whole lot of options
to begin reporting themselves in the "wrong" sense, creating confusion
for both new and longtime users.  The compromise that was reached was
to have "setopt" by default display only the options that differed from
their default settings.

} Wouldn't we almost always want to see what the options are set to?

Who is this "we" of whom you speak?

If there were a lot fewer than 175 options, then possibly yes, but
defaulting to dumping that much information is just overwhelming; you
can't even begin to handle it without piping it to a pager.

} And if not, can't we have " $ setopt -v " to achieve the same thing?

"set -o" will do what you want -- but note that comes from /bin/sh where
there maybe a dozen possible options to report.  Even bash has only a
bit over two dozen.

"setopt -v" sets the VERBOSE option, and though there is some precedent
for mucking with that (i.e., "setopt -m" does *not* set MONITOR) there
would need to be a better reason to replace -v.

On the other hand "setopt -o" just throws an error if not followed by
an option name, so we could consider redefining *that* like "set -o".

Aside:  Does anybody have a sensible use case for the pattern-matching
behavior of "setopt -m"?  "setopt -m posix\*" maybe?