Groups | Search | Server Info | Keyboard shortcuts | Login | Register
Groups > gnu.bash.bug > #16874
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Incorrect / Inconsistent behavior with nameref assignments in functions |
| Date | 2020-08-31 11:21 -0400 |
| Organization | ITS, Case Western Reserve University |
| Message-ID | <mailman.1870.1598887295.2469.bug-bash@gnu.org> (permalink) |
| References | <a20e4692-69b3-9836-4861-3e822e407ef7@binarus.de> <22c90c38-aa7b-1d89-e0e8-d6d87b22b604@case.edu> |
On 8/28/20 4:56 AM, Binarus wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > > Description: > ------------ > > Under certain circumstances, assignments of namerefs to local variables > in functions behaves in a way which makes namerefs completely useless. > Furthermore, the behavior is not consistent. There is an order of evaluation problem as explained later in the thread, not specific to namerefs. It's fixed in bash-5.1. The underlying issue is making `declare [options] foo=bar' expand the argument like an assignment statement as POSIX specifies. This makes `declare' more like a hybrid reserved word instead of a builtin. In some cases, the options matter and affect how the argument gets expanded. You end up having to do something like `declare [options] foo; foo=bar' to get the expansion right, but that introduces several corner cases. -- ``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/
Back to gnu.bash.bug | Previous | Next | Find similar
Re: Incorrect / Inconsistent behavior with nameref assignments in functions Chet Ramey <chet.ramey@case.edu> - 2020-08-31 11:21 -0400
csiph-web