* setopt
@ 2014-11-30 20:10 Ray Andrews
2014-12-01 3:31 ` setopt Bart Schaefer
0 siblings, 1 reply; 3+ messages in thread
From: Ray Andrews @ 2014-11-30 20:10 UTC (permalink / raw)
To: Zsh Users
Just reading in the Dead Sea Scrolls, I discover 'setopt
-ksh_option_print', which makes " $ setopt " (by itself) actually
useful. Shouldn't that be the default? Wouldn't we almost always want
to see what the options are set to? And if not, can't we have " $
setopt -v " to achieve the same thing?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: setopt
2014-11-30 20:10 setopt Ray Andrews
@ 2014-12-01 3:31 ` Bart Schaefer
2014-12-01 4:34 ` setopt Ray Andrews
0 siblings, 1 reply; 3+ messages in thread
From: Bart Schaefer @ 2014-12-01 3:31 UTC (permalink / raw)
To: Zsh Users
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?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: setopt
2014-12-01 3:31 ` setopt Bart Schaefer
@ 2014-12-01 4:34 ` Ray Andrews
0 siblings, 0 replies; 3+ messages in thread
From: Ray Andrews @ 2014-12-01 4:34 UTC (permalink / raw)
To: zsh-users
On 11/30/2014 07:31 PM, Bart Schaefer wrote:
> "set -o" will do what you want -- but note that comes from /bin/sh where
Thanks Bart, that's just fine. So no need for 'ksh_option_print' after
all. I got that
from Oliver's book. I think I got my wires crossed between 'set' and
'setopt'.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-12-01 4:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-30 20:10 setopt Ray Andrews
2014-12-01 3:31 ` setopt Bart Schaefer
2014-12-01 4:34 ` setopt Ray Andrews
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).