From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11704 invoked by alias); 2 Mar 2011 03:33:57 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28840 Received: (qmail 17514 invoked from network); 2 Mar 2011 03:33:56 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) MIME-Version: 1.0 Date: Tue, 1 Mar 2011 19:02:33 -0800 Message-ID: Subject: readonly, export, and local From: Bart Schaefer To: Zsh hackers list Content-Type: text/plain; charset=ISO-8859-1 Chet Ramey on the austin-group list: > ksh93 does dynamic scoping if the local > variable shadows a global variable with the export attribute set. This > means that it will pass the local variable value to both child functions > and external commands, and not permit a local variable with the same name > as a global variable with both the export and readonly attributes (in > fact, that is a fatal error). This has me wondering whether zsh should do something similar. If I have declared an exported variable as readonly, does that not imply that I expect that value to be the one placed in the environment of any external command that may be executed? Yet zsh allows "local -x" to cause the local copy of a variable to go into the environment instead, even when the variable of the same name in the surrounding scope is marked readonly. Certainly either semantics could be argued. Zsh's current behavior provides a slightly better illusion of lexical scope.