From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-37290-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 29124 invoked by alias); 3 Dec 2015 14:40:14 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 37290
Received: (qmail 6171 invoked from network); 3 Dec 2015 14:40:13 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.0
X-AuditID: cbfec7f5-f79b16d000005389-60-5660544b21bd
Date: Thu, 03 Dec 2015 14:40:08 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: a way to get the value of the -c option
Message-id: <20151203144008.1bf3641b@pwslap01u.europe.root.pri>
In-reply-to: <20151203142355.31af16ce@pwslap01u.europe.root.pri>
References: <20151203115449.GA19846@zira.vinc17.org>
 <20151203124554.3b93281f@pwslap01u.europe.root.pri>
 <20151203133626.GA29715@zira.vinc17.org>
 <20151203140118.5ca77f8c@pwslap01u.europe.root.pri>
 <20151203142355.31af16ce@pwslap01u.europe.root.pri>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsVy+t/xK7reIQlhBqdWClgcbH7I5MDoserg
	B6YAxigum5TUnMyy1CJ9uwSujPcT5AqucVQ8X7iVvYHxOVsXIweHhICJxL/jdl2MnECmmMSF
	e+uBwlwcQgJLGSWa18xmgnBmMEkc/b6TFaRKSOA0o8SOQ+oQiTOMEp0vLjGCJFgEVCUaJ29h
	AbHZBAwlpm6aDRYXERCXOLv2PFhcGGjb5ZatTCA2r4C9xPN538BqOAUcJP5ev8sKMbSRSeLW
	sllgRfwC+hJX/35igrjPXmLmlTOMEM2CEj8m3wMbyiygJbF5WxMrhC0vsXnNW2aIS9Ulbtzd
	zT6BUXgWkpZZSFpmIWlZwMi8ilE0tTS5oDgpPddIrzgxt7g0L10vOT93EyMkmL/uYFx6zOoQ
	owAHoxIPr4BnfJgQa2JZcWXuIUYJDmYlEd4ot4QwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwz
	d70PERJITyxJzU5NLUgtgskycXBKNTAGswk8mVF4N/FXalMqw9tLravnbjqZnPyV2ZuV3eyP
	5UaHufsPKrS+2F/7ISq2c+9WydeNycv7Xyt4FbRMcPzyL2xO74I64fkR9cerDrVn3VqSoPh6
	rWaEjtN5YcH3oo5CmzYwLZj6b4v12l1iFxxFrkWWTWUP+u1TMeOUaewt5Vjj/afXey1TYinO
	SDTUYi4qTgQA9J3GSmICAAA=

On Thu, 3 Dec 2015 14:23:55 +0000
Peter Stephenson <p.stephenson@samsung.com> wrote:
> I'm wondering about that "restricted", too (defined just below).  It's
> only there as a flag between option parsing and init_misc() where the
> option is actually set.  This raises the question of what should we do
> when when parseopts is called from emulate and any "restricted" setting
> currently disappears into the ether.  That can't be right, can it?  Do
> we honour it, or we do we print an error?

Ah, wait, it's deliberate --- the test for !nam after the test for
restricted means it doesn't get passed on, and instead we drop through
to normal option setting, which already handles attempts to change this.
It's just a bit obscure.

I might turn the static into an argument, pass a pointer here, and test
for the pointer, rather than !nam, and then I might know what's going
on...

		} else if (optno == RESTRICTED && !nam) {
		    restricted = action;
...
		} else {
		    if (dosetopt(optno, action, !nam, new_opts) && nam) {
			WARN_OPTION("can't change option: %s", *argv);

pws