Groups | Search | Server Info | Keyboard shortcuts | Login | Register


Groups > gnu.bash.bug > #16860

Re: Incorrect / Inconsistent behavior with nameref assignments in functions

Path csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From Koichi Murase <myoga.murase@gmail.com>
Newsgroups gnu.bash.bug
Subject Re: Incorrect / Inconsistent behavior with nameref assignments in functions
Date Sun, 30 Aug 2020 09:59:20 +0900
Lines 72
Approved bug-bash@gnu.org
Message-ID <mailman.1746.1598749178.2469.bug-bash@gnu.org> (permalink)
References <a20e4692-69b3-9836-4861-3e822e407ef7@binarus.de> <CAFLRLk8xc4CAR7X_g-B-QMCNtvzVkv5E9kf3EUiD_JUACAfwDA@mail.gmail.com> <5f512e22-fe55-7281-7585-7cffb74299dc@binarus.de> <CAFLRLk9mfWJh5e_8=diERYAAZE7AwPu4YfF-1J-89697itYLrQ@mail.gmail.com>
NNTP-Posting-Host lists.gnu.org
Mime-Version 1.0
Content-Type text/plain; charset="UTF-8"
X-Trace usenet.stanford.edu 1598749179 11868 209.51.188.17 (30 Aug 2020 00:59:39 GMT)
X-Complaints-To action@cs.stanford.edu
Cc bug-bash@gnu.org
To Binarus <lists@binarus.de>
Envelope-to bug-bash@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XtqgMukZh/9L4RNtLlTuSUuuSojtr6o7gqzs/qi1JQg=; b=pH86TieVopr5JOwQxVD0ll1UoRUYJFApLo4oh2oiUgxxFHpTNOXOTsMysv2ZeDi9lX lcMqPdmEjOQ+/YTgldmkXKJQ+l3VOjpwLGCU76VIurTysmbpuT7y2h9EDfcXsyn75Oet gYVQWectsR3qxkNmRje8BcYB8T3/elXRX90BfmSz/gnOMXO1uZU485VrkEi/zsRxXL+Z 5LV1CRtICbJrkQLNWnqOwLf3rVPIP2GEAZ0T3b9SaUhluhqqmd8ARF5qU9fQb8crdwK2 JhmhCqjKlXzJwlfPc+6U8DoQ8oSWnFNn8pfPF868uIg1s3L3GZpr60ZiAHW9X0ggfdDt mPag==
X-Google-DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XtqgMukZh/9L4RNtLlTuSUuuSojtr6o7gqzs/qi1JQg=; b=OZdaSrExZifBoAhumQxiqTxIRQ4dbqD3UvGYfbDIP+4ICKECP2U3QcG9Kkpcb4GrHt lIiBUgpTOXig72kUmNLMTYMGFWJKrszpYXKpuod7iJ5ONyPFtrY7OySSCfcD5yqAWrok mmDKUSWe361hxbgJQue+twzC4s57oLug/PJMbqwTIC/8SAfl4zrSgr3hEd0KheI8/fCm QcC3MbJLss+ac6Ekq3Tw9bZ9l9Ou7zIFjbJS4EqUUEmWIQLrJPch0VbuHMcRyElumByT 5ZvXFldxqf/88YCAhwv2Q9S08uFcnofL/eQZAuKDVR1I8t6TRvM8q66voqqaruFVimZ2 jY0g==
X-Gm-Message-State AOAM533Yc9bizfzKnFU7X8T3X6t6AnkWu40NEJF1d4bVwRiC86Zgztqd hWaaYxEYiRz2VwrLxKsBSj1B9pP7XU8Ehs8YTjcpzkYj0Y+qYA==
X-Google-Smtp-Source ABdhPJwDhUJj/IOx1SCTpB5b4wU33BTQkHXuQXCjvUyKOnSr9VzJu+jA1Ov7BTS9JracRujpbremBONLR2K5ycRIAc8=
X-Received by 2002:a50:8c66:: with SMTP id p93mr5598804edp.156.1598749172840; Sat, 29 Aug 2020 17:59:32 -0700 (PDT)
In-Reply-To <5f512e22-fe55-7281-7585-7cffb74299dc@binarus.de>
Received-SPF pass client-ip=2a00:1450:4864:20::529; envelope-from=myoga.murase@gmail.com; helo=mail-ed1-x529.google.com
X-detected-operating-system by eggs.gnu.org: No matching host in p0f cache. That's all we know.
X-Spam_score_int -20
X-Spam_score -2.1
X-Spam_bar --
X-Spam_report (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action no action
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.23
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <https://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID <CAFLRLk9mfWJh5e_8=diERYAAZE7AwPu4YfF-1J-89697itYLrQ@mail.gmail.com>
X-Mailman-Original-References <a20e4692-69b3-9836-4861-3e822e407ef7@binarus.de> <CAFLRLk8xc4CAR7X_g-B-QMCNtvzVkv5E9kf3EUiD_JUACAfwDA@mail.gmail.com> <5f512e22-fe55-7281-7585-7cffb74299dc@binarus.de>
Xref csiph.com gnu.bash.bug:16860

Show key headers only | View raw


2020-08-29 14:46 Binarus <lists@binarus.de>:
> I am wondering when debian will include bash 5.1. It looks like
> debian testing and debian unstable are on bash 5.0, so it will
> probably take several years.

Actually the problem of the function `Dummy' will not be solved even
in bash 5.1.  There is another but similar problem with your function.
A user might specify `namerefArray' as the name of an outer array,
which results in a circular-reference error.

  $ cat testR2c.sh
  function Dummy {
    local -n namerefArray="$1"
    local -a -i myArray=("${namerefArray[@]}")
    local -p
  }
  declare -a -i namerefArray=('1' '2' '3')
  Dummy namerefArray

  $ bash-5.1-alpha testR2c.sh
  testR2c.sh: line 4: local: warning: namerefArray: circular name reference
  testR2c.sh: line 4: warning: namerefArray: circular name reference
  testR2c.sh: line 5: warning: namerefArray: circular name reference
  testR2c.sh: line 5: warning: namerefArray: circular name reference
  declare -a myArray=([0]="1" [1]="2" [2]="3")
  declare -n namerefArray="namerefArray"

If you want to work around the problem, there are several ways.

* One of the simplest ways is to use different variable names as
  already suggested by other people.  However, when the variable name
  is not under control for some reason (that, e.g., the functon is
  provided to users who may use it in an arbitrary way, or it imports
  different shell-script frameworks), the probability of the name
  collision is not 0%.

* Another way is to copy to the local array only when the name is
  different from `myArray':

  function Dummy {
    [[ $1 == myArray ]] ||
      eval "local -a myArray=(\"\${$1[@]}\")"
    declare -p myArray
  }

  When you want to add `-i' attribute to the array or to modify the
  array without affecting the original outer array, you may first save
  the value to another local array and next copy the array to the
  array that you want to edit.

  function Dummy {
    [[ $1 == inputArray ]] ||
      eval "local -a inputArray=(\"\${$1[@]}\")"
    local -ia myArray=("${inputArray[@]}")
    declare -p myArray
  }

* If you want to use namerefs to eliminate the use of `eval', maybe
  you could do like the following but I think it is more natural and
  readable to use eval:

  function Dummy {
    [[ $1 == refArray ]] || local -n refArray=$1
    [[ $1 == inputArray ]] || local -i inputArray=("${refArray[@]}")
    local -ia myArray=("${inputArray[@]}")
    declare -p myArray
  }

Best regards,

Koichi

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: Incorrect / Inconsistent behavior with nameref assignments in functions Koichi Murase <myoga.murase@gmail.com> - 2020-08-30 09:59 +0900

csiph-web