On 8/28/20 11:28 AM, Greg Wooledge wrote:
>
> You've got a local variable with the same name as the global variable
> that you're attempting to pass by reference. This will not work.
>
> Namerefs (declare -n) in bash are *not* like uplevel commands in Tcl.
> They cause the referenced variable n
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
On 30.08.2020 20:01, Koichi Murase wrote:
> 2020-08-30 19:24 Binarus :
> Yes, I recognize the problem when the function isn't properly used.
> But, the use of eval itself is not fatal. When another user can call
> the function as in your example,
>
> Dummy 'myArray1[@]}"); echo Gotcha!; #'
>
On 30.08.2020 16:50, Greg Wooledge wrote:
> The evil thing here is code injection. Obviously eval is one way to
> perform code injection, but it's not the *only* way. Eval itself isn't
> evil; if anything, it's all of the other forms of code injection,
> which people don't suspect, that are tr
2020-08-30 19:24 Binarus :
> Actually, this is what first happened to me and what led me to the
> problem described in my original post.
>
> [...]
Thank you for your explanation! Now I see your situation.
>> * Another way is to copy to the local array only when the name is
>> different from `my
On Sun, Aug 30, 2020 at 12:24:03PM +0200, Binarus wrote:
> On 30.08.2020 02:59, Koichi Murase wrote:
> > * 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=(\"\
On 30.08.2020 02:59, Koichi Murase wrote:
> 2020-08-29 14:46 Binarus :
>> 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
2020-08-29 14:46 Binarus :
> 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 simil
Thank you very much for your effort, testing and support!
On 29.08.2020 01:46, Koichi Murase wrote:
> 2020-08-28 22:04 Binarus :
>> Description:
>>
>>
>> Under certain circumstances, assignments of namerefs to local variables
>> in functions behaves in a way which makes namerefs compl
At first, thank you very much for your effort and the understandable
explanation.
On 28.08.2020 20:28, Robert Elz wrote:
> Date:Fri, 28 Aug 2020 18:25:23 +0200
> From:Binarus
> Message-ID: <8313a366-6ecd-5e87-5552-6a4e0fe18...@binarus.de>
>
>
> | > This doesn't ma
On 28.08.2020 22:08, Oğuz wrote:
>
> 5.1 is still in beta phase.
I see. I couldn't use it anyway because the script in question (where I
make heavy use of namerefs and nested function calls) is for production,
and I won't use software which I need to compile myself on those servers
for security
2020-08-28 22:04 Binarus :
> 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.
This is actually not related to namerefs and
28 Ağustos 2020 Cuma tarihinde Binarus yazdı:
>
>
> On 28.08.2020 17:37, Oğuz wrote:
> > 28 Ağustos 2020 Cuma tarihinde Greg Wooledge
> yazdı:
> >
> >> On Fri, Aug 28, 2020 at 10:56:34AM +0200, Binarus wrote:
> >>> #!/bin/bash
> >>>
> >>> function Dummy() {
> >>>
> >>> local -n namerefArray="$
Date:Fri, 28 Aug 2020 18:25:23 +0200
From:Binarus
Message-ID: <8313a366-6ecd-5e87-5552-6a4e0fe18...@binarus.de>
| > This doesn't make the slightest sense. What is the point of having local
| > variables then?
|
| Or namerefs ... I totally agree. Either locals
On Fri, Aug 28, 2020 at 06:20:04PM +0200, Binarus wrote:
> However, the main question is why leaving away the -a and -i in the
> second script makes things work as expected.
I'll leave aside my usual rant about -i for now. Here's your original
code:
#!/bin/bash
function Dummy() {
local -n na
On 28.08.2020 17:37, Oğuz wrote:
> 28 Ağustos 2020 Cuma tarihinde Greg Wooledge yazdı:
>
>> On Fri, Aug 28, 2020 at 10:56:34AM +0200, Binarus wrote:
>>> #!/bin/bash
>>>
>>> function Dummy() {
>>>
>>> local -n namerefArray="$1"
>>> local -a -i myArray=("${namerefArray[@]}")
>>>
>>> local
On 28.08.2020 17:28, Greg Wooledge wrote:
> On Fri, Aug 28, 2020 at 10:56:34AM +0200, Binarus wrote:
>> #!/bin/bash
>>
>> function Dummy() {
>>
>> local -n namerefArray="$1"
>> local -a -i myArray=("${namerefArray[@]}")
>>
>> local -p
>> }
>>
>> declare -a -i myArray=('1' '2' '3')
>
> You
On Fri, Aug 28, 2020 at 06:37:00PM +0300, Oğuz wrote:
> 28 Ağustos 2020 Cuma tarihinde Greg Wooledge yazdı:
> > func1() {
> > declare -n _func1_ref="$1"
> > local _func1_i
> > ...
> > }
> >
> This doesn't make the slightest sense. What is the point of having local
> variables then?
You need
28 Ağustos 2020 Cuma tarihinde Greg Wooledge yazdı:
> On Fri, Aug 28, 2020 at 10:56:34AM +0200, Binarus wrote:
> > #!/bin/bash
> >
> > function Dummy() {
> >
> > local -n namerefArray="$1"
> > local -a -i myArray=("${namerefArray[@]}")
> >
> > local -p
> > }
> >
> > declare -a -i myArray=('
On Fri, Aug 28, 2020 at 10:56:34AM +0200, Binarus wrote:
> #!/bin/bash
>
> function Dummy() {
>
> local -n namerefArray="$1"
> local -a -i myArray=("${namerefArray[@]}")
>
> local -p
> }
>
> declare -a -i myArray=('1' '2' '3')
You've got a local variable with the same name as the global
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR$
uname output: Linux cerberus
21 matches
Mail list logo
