Path: csiph.com!xmission!news.alt.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!171.64.64.130.MISMATCH!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: [BUG] 'unset' fails silently under specific conditions Date: Wed, 2 May 2018 15:27:41 -0400 Lines: 80 Approved: bug-bash@gnu.org Message-ID: References: <1295e1ea-73c0-e479-da03-b784ec975030@inlv.org> <59161dc5-bb33-d842-4af3-477e8784a4f5@inlv.org> <71d753dc-036f-7fd7-d703-408c3f8ac202@case.edu> <48f7a2c2-70ce-0994-33e0-6b2282a3b5f6@inlv.org> Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: usenet.stanford.edu 1525289272 22826 208.118.235.17 (2 May 2018 19:27:52 GMT) X-Complaints-To: action@cs.stanford.edu Cc: chet.ramey@case.edu To: Martijn Dekker , bug-bash@gnu.org Envelope-to: bug-bash@gnu.org Openpgp: preference=signencrypt Autocrypt: addr=chet.ramey@case.edu; prefer-encrypt=mutual; keydata= xsDiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJM0gQ2hldCBSYW1l eSA8Y2hldC5yYW1leUBjYXNlLmVkdT7CYQQTEQIAIQIbAwYLCQgHAwIDFQIDAxYCAQIeAQIX gAUCRX3FIgIZAQAKCRC7WGnwZOp0q069AKCNDRn+zzN/AHbaynls/Lvq1kH/RQCgkLvF8bDs maUHSxSIPqzlGuKWDxbOwE0EQQ6wbxAEAJCukwDigRDPhAuI+lf+6P64lWanIFOXIndqhvU1 3cDbQ/Wt5LwPzm2QTvd7F+fcHOgZ8KOFScbDpjJaRqwIybMTcIN0B2pBLX/C10W1aY+cUrXZ gXUGVISEMmpaP9v02auToo7XXVEHC+XLO9IU7/xaU98FL69l6/K4xeNSBRM/AAMHA/wNAmRB pcyK0+VggZ5esQaIP/LyolAm2qwcmrd3dZi+g24s7yjV0EUwvRP7xHRDQFgkAo6++QbuecU/ J90lxrVnQwucZmfz9zgWDkT/MpfB/CNRSKLFjhYq2yHmHWT6vEjw9Ry/hF6Pc0oh1a62USdf aKAiim0nVxxQmPmiRvtCmcJJBBgRAgAJBQJBDrBvAhsMAAoJELtYafBk6nSr43AAn2ZZFQg8 Gs/zUzvXMt7evaFqVTzcAJ0cHtKpP1i/4H4R9+OsYeQdxxWxTQ== User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 In-Reply-To: Content-Language: en-US X-Junkmail-Status: score=7/90, host=mpv4-2015.case.edu X-Junkmail-PrAS-Raw: score=7/90, refid=2.7.2:2018.5.2.183616:17:7.944, ip=, rules=__HAS_REPLYTO, __HAS_CC_HDR, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __TO_MALFORMED_2, __TO_NAME, __TO_NAME_DIFF_FROM_ACC, __REFERENCES, __HAS_FROM, FROM_EDU_TLD, __HAS_MSGID, __SANE_MSGID, DATE_TZ_NA, __USER_AGENT, __MOZILLA_USER_AGENT, __MIME_VERSION, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __FROM_DOMAIN_IN_ANY_CC1, __FROM_DOMAIN_IN_ANY_CC2, __REPLYTO_SAMEAS_FROM_DOMAIN, __ANY_URI, __URI_WITH_PATH, __URI_NO_WWW, __CP_URI_IN_BODY, __HIGHBITS, __SUBJ_ALPHA_NEGATE, __URI_IN_BODY, __URI_NOT_IMG, __FORWARDED_MSG, __NO_HTML_TAG_RAW, BODY_SIZE_3000_3999, __MIME_TEXT_P1, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, IN_REP_TO, MSG_THREAD, __FROM_DOMAIN_IN_RCPT, __TO_REAL_NAMES, MULTIPLE_REAL_RCPTS, LEGITIMATE_SIGNS, __SINGLE_URI_TEXT, [TRUNCATED], so=2010-03-03 19:42:08, dmn=2016-08-03-0138 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 129.22.103.195 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14083 On 5/2/18 10:07 AM, Martijn Dekker wrote: > Op 02-05-18 om 02:20 schreef Chet Ramey: >> You complained that `typeset +x' didn't `unexport' a variable.  The >> reason > is that the variable assignment preceding the special builtin >> caused a >> variable to be created at the global scope, and the `typeset' resulted in >> a local variable being created. > > I still can't see how that is relevant here: 'typeset'/'declare' is not > involved in the current issue. But then, neither is 'unset'. It does appear > that the current issue is not what I thought it was. > > Instead, in POSIX mode, it looks like a variable assignment preceding a > special builtin may create a variable at a function-local scope without > 'typeset'/'declare' being involved at all. But not always. Mostly correct. It creates a variable that claims to be at the global scope (context == 0, internally), but is placed in the wrong variable table. This is the bug. It manifests itself in different ways. What we're trying to figure out is the right semantics: should it continue to create the variable at the global scope (context == 0) and make sure it is inserted into the correct variable table (global_variables), or should it create a variable at the current scope (context == current_variable_context) and insert it into the variable table at the current scope (shell_variables). > > Let's see if I'm getting it right this time. In the following: >     set -o posix >     f() { foo=bar : ; } >     f > the command 'foo=bar :' > 1. makes the assignment 'foo=bar' survive the ':' command; > 2. gives 'foo' a global scope; > 3. permanently exports the global variable 'foo'. > > However, in the following: >     set -o posix >     f() { foo=bar; foo=baz : ; } >     f > the plain assignment 'foo=bar' creates an ordinary global variable named > 'foo' with value 'bar', and then the command 'foo=bar :' > 1. makes the assignment 'foo=baz' survive the ':' command, but by creating > *another* 'foo' instead of overwriting the first; > 2. gives that other 'foo' a function-local scope; > 3. exports the local variable 'foo' for the duration of its existence. Pretty much. > My testing confirms that this is what appears to happen, and I think it's a > bug, because (1) POSIX has no notion of variables with a function-local > scope; (2) even if it did, no command was issued that should make the > variable local to the function; and (3) the behaviour in the second example > is inconsistent with that in the first. > > I think 'foo=baz :' should act the same in the second example as 'foo=bar > :' does in the first, i.e.: if there is already a variable by that name it > should be overwritten, just like with any normal shell assignment. If there is an existing global variable by that name, you mean. If there is an existing local variable, the assignment preceding the special builtin will completely bypass it and modify the global scope. (Just to make things a little more interesting, if you use ksh-style functions to test local variables -- since Posix-style functions don't have local variables -- ksh93 modifies an existing local variable instance.) My original fix was the second alternative described above, which is similar to the ksh93 local variable behavior: create or modify a local variable instance if executing within a shell function. After our subsequent discussion, and this second report, I modified it to implement the first alternative: create and modify global variables and leave existing local variables unaltered. We'll see how that goes. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/