From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24593 invoked by alias); 1 Dec 2014 03:32:20 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 19472 Received: (qmail 5118 invoked from network); 1 Dec 2014 03:32:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=IOK10brD c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=5y4faFyK3SkA:10 a=Cowx2sQD-tHnkCbR4EgA:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141130193147.ZM29029@torch.brasslantern.com> Date: Sun, 30 Nov 2014 19:31:47 -0800 In-reply-to: <547B79A6.1030003@eastlink.ca> Comments: In reply to Ray Andrews "setopt" (Nov 30, 12:10pm) References: <547B79A6.1030003@eastlink.ca> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh Users Subject: Re: setopt MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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?