Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: assignment to a nameref that resolves to the temporary environment Date: Tue, 11 Dec 2018 15:37:08 -0500 Organization: ITS, Case Western Reserve University Lines: 39 Approved: bug-bash@gnu.org Message-ID: References: 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: 7bit X-Trace: usenet.stanford.edu 1544560641 8459 208.118.235.17 (11 Dec 2018 20:37:21 GMT) X-Complaints-To: action@cs.stanford.edu Cc: chet.ramey@case.edu To: Grisha Levit , bug-bash Envelope-to: bug-bash@gnu.org X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:cc:subject:to:references:from:openpgp :autocrypt:organization:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=eE1VCWQ6SnMPCEPF1iyOYTL9rMQ+OdTVYOV2Pbj6Z2s=; b=i+8NdzyWYzTnENq4AjL+ii9xxMac2Rds0PiX2LGkcL98twmE5pCLDnh66U4oJn+xb9 3wO1vtJBQVbxlIh+hQUVJLJzYCvPQdzBEBSWuSdiuy0ITop9lkNH8gR7/kZG2BIk8lxG 6YoOPk5CXo2iKbvXs+6T32YsekuA9MCiQL/RjEyEecTBLielkUzEiAX+sIiE6eIZ/Rfp wcriXi87G3kXKOn70wcJK7ojGQm/783/7WtOmLC7D09L4ECVSZR+3ikbEbrypBUacGaU /9k500X5omw6sC6d4YfVKpPfm+LF2mmsY0uLANe/THFYjZpycJ8LdV9E3EALBkt8BSAL ENAQ== X-Gm-Message-State: AA+aEWYpCaqHxBUDULvLdwQFHdcO4OCoHV2rOWztmIYmqa2T1PaAw0Vb HgqigCtLVD8jXCzGYG19amWqbwMyHXoNGkdZc/JWv3C1luzcKOLfbHOfTTdAv4EScrbRW1IT4bQ EeRZkeJ140tE= X-Received: by 2002:a24:a3c7:: with SMTP id p190mr2287788ite.39.1544560630746; Tue, 11 Dec 2018 12:37:10 -0800 (PST) X-Google-Smtp-Source: AFSGD/WNTjztjpDHE+u+VFijGy+M34Jjh9Je8PaMQQKo4d0fRecS2thoh6BcAVyaCZyjC8vyGi/CRQ== X-Received: by 2002:a24:a3c7:: with SMTP id p190mr2287774ite.39.1544560630462; Tue, 11 Dec 2018 12:37:10 -0800 (PST) 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/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJM0aQ2hldCBSYW1l eSA8Y2hldEBjd3J1LmVkdT7CYQQTEQIAIQIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAUCQ+La kQIZAQAKCRC7WGnwZOp0q9rGAJ4sRGLmlF8klZTH75z7jyQScpU6aACeNMahjWIhumt4u96d 9mdMJqlabVnOwE0EQQ6wbxAEAJCukwDigRDPhAuI+lf+6P64lWanIFOXIndqhvU13cDbQ/Wt 5LwPzm2QTvd7F+fcHOgZ8KOFScbDpjJaRqwIybMTcIN0B2pBLX/C10W1aY+cUrXZgXUGVISE MmpaP9v02auToo7XXVEHC+XLO9IU7/xaU98FL69l6/K4xeNSBRM/AAMHA/wNAmRBpcyK0+Vg gZ5esQaIP/LyolAm2qwcmrd3dZi+g24s7yjV0EUwvRP7xHRDQFgkAo6++QbuecU/J90lxrVn QwucZmfz9zgWDkT/MpfB/CNRSKLFjhYq2yHmHWT6vEjw9Ry/hF6Pc0oh1a62USdfaKAiim0n VxxQmPmiRvtCmcJJBBgRAgAJBQJBDrBvAhsMAAoJELtYafBk6nSr43AAn2ZZFQg8Gs/zUzvX Mt7evaFqVTzcAJ0cHtKpP1i/4H4R9+OsYeQdxxWxTQ== User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 In-Reply-To: Content-Language: en-US X-Junkmail-Status: score=9/90, host=mpv2-2015.case.edu X-Junkmail-PrAS-Raw: score=9/90, refid=2.7.2:2018.12.11.200616:17:9.975, ip=, rules=__YOUTUBE_RCVD, __X_GOOGLE_DKIM_SIGNATURE, __HAS_REPLYTO, __HAS_CC_HDR, __SUBJ_REPLY, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __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, __FRAUD_REFNUM, __CP_URI_IN_BODY, __FRAUD_MONEY_CURRENCY_DOLLAR, __SUBJ_ALPHA_NEGATE, __URI_IN_BODY, __URI_NOT_IMG, __FORWARDED_MSG, __NO_HTML_TAG_RAW, BODY_SIZE_1700_1799, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_P1, __MIME_TEXT_ONLY, __URI_NS, SXL_IP_PROXY_RCVD[125.239.219.74.rip], HTML_00_01, HTML_00_10, [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.227 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:14906 On 12/9/18 1:28 AM, Grisha Levit wrote: > When a nameref local to a higher function scope points to a variable in the > temporary environment, that nameref (correctly, it seems) expands to the > value > of the target variable from the temporary environment. However, assignment > to > the nameref modifies the variable from the higher scope, bypassing the > tempenv: > > $ a() { local -n ref=var; var=tmp b; echo $ref; } > $ b() { ref=$ref; } > $ var=foo; a > tmp Here's what happens when you execute `b'. The variable `var' is put into the temporary environment with value `tmp'. The resolution for $ref looks at the current environment, finds nothing, looks at the previous environment (a), and finds a nameref with value `var'. It *restarts* the lookup to resolve `var', finds it in the temporary environment, and expands to `tmp'. So that's the value, and the assignment becomes `ref=tmp'. The assignment code goes looking for `ref' and finds it in the previous context as a nameref with value `var'. This is where the asymmetry occurs. When performing an assignment, the shell starts at the context where the nameref is found, rather than starting at the original context -- which in this case, would have found the variable in b's temporary environment. Do you think it's reasonable to have this restriction, given the nature of bash's dynamic variable scoping, or should it restart the lookup from the original variable context? You can get yourself into some pretty nasty nameref loops if you go back to the original context. Chet -- ``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/