Re: bash local

[Ronald van Engelen <ronalde+enosig@xxxxxxxxxxx>]

Op 28-05-18 om 14:54 schreef Casper Gielen:
> Op 25-05-18 om 20:29 schreef Wim:
>> Hoi Joost, Allen,
>>
>>>> function localtest()
>>>> {
>>>> 	local aaaa=$1
>>>> 	eval "$2='$aaaa'"
>>>> }
>>>>
>>>> echo Andere variablenaam
>>>> localtest 34 result
>>>> echo $result
>>>>
>>>> echo "Variablenaam die ook in de functie (als local) voorkomt"
>>>> localtest 34 aaaa
>>>> echo $aaaa
>>>
>>> Dank je, dat maakt t voor mij ietsje duidelijker.
> 
> Hoi Wim,
> binnen localtest is 'aaaa' een lokale variabele. Wat je ook doet, buiten
> die functie is die variabele niet meer zichtbaar. Dat je er later een
> andere waarde in stopt verandert daar niks meer aan, die variabele is al
> gemarkeerd als local.
> 
>>>>>  eval "$3='$cccc'"
>>>
>>>> Wat is daar eng aan? cccc wordt in $3 gezet waardoor de waarde van cccc
>>>> terugkan naar de aanroepende functie. Mogelijk is er een nettere oplossing
>>>> maar die heb ik ondanks het nodige onderzoek lange tijd geleden nog niet
>>>> gevonden. Dit werkt goed voor allerhande variablen.
> 
> eval maakt code over het algemeen erg lastig om te begrijpen en een stuk
> minder voorspelbaarder. Veel programmeurs proberen eval-constructies dus
> zo veel mogelijk te vermijden.
> 
>> Dat zou mooi zijn. Als je, iemand een idee hebt / heeft . . . .
> 
> Het is mij niet duidelijk wat je precies probeert te bereiken.
> Runtime variabelen aanmaken waarbij de naam zelf variabel is niet echt
> gebruikelijk. Is dit het hele doel van de excercitie?
> 
> Gaat het je om hoe je variabelen retourneert naar de parent?
> 
> mytestfunc() {
>   local result = "$1 en $2"
>   echo "$result"
> }
> 
> myresult=$(mytestfunc aaa bbb)
> 
> 
>>> en ik vermoed dat dan ook dat
>>> local-probleem (misschien is dat wel bug in bash) je niet meer dwars zit.
>>
>> Er is gemakkelijk om heen te werken. Het zit me dus niet dwars. Wat wel het gevolg is is dat er opgelet moet worden bij het kiezen van variable namen. Werkt de local functie wel vraag ik mij af.
>> Ik liep er tegen aan tijdens het schrijven van een programma en toen heb ik een proof of concept script geschreven. Mogelijk is het inderdaad een bug.
>>
>>> Het feit dat aanroepen van
>>>
>>>  localtest a b
>>>
>>> een variable met de naam $b creeert is voor mij onverwacht.  Had niet gedacht
>>> dat zoiets kon in bash.  Ik ben gewend dat argumenten van functies door
>>> functies gelezen worden, en niet gebruikt worden als variabele-namen.
>>
>> Zo zie je maar weer :-)
> 
> Je breekt door scope-grenzen heen op een manier die onder bash werkt
> maar in de meeste andere programmeertalen niet zomaar mogelijk is, of
> waar op z'n minst zeer op wordt neergekeken.
> 

Hallo allen,

Voor dit soort debugging in bash scripts gebruik ik vaak `declare -p' en
de ingebouwde bash variabelen `LINENO' en `FUNCNAME' (de laatste is een
indexed array):

## start script
#!/usr/bin/env bash

function localtest()
{
    local aaaa=$1
    declare -p LINENO FUNCNAME aaaa
    eval "$2='$aaaa'"
}

function nonlocaltest()
{
    aaaa=$1
    declare -p LINENO FUNCNAME aaaa
    eval "$2='$aaaa'"
}

echo "geen aaaa, wordt in externe functie local gedeclareerd"
localtest 34 result
declare -p LINENO FUNCNAME aaaa result

echo "local aaaa, wordt ook in de externe functie local gedeclareerd"
unset aaaa
local aaaa
localtest 34 aaaa
declare -p LINENO FUNCNAME aaaa

echo "geen aaaa, wordt in externe functie (niet local) gedeclareerd"
unset aaaa
nonlocaltest 34 result
declare -p LINENO FUNCNAME aaaa result
## eind script

Misschien dat dat nieuw licht op de zaak werpt?

Gegroet,
Ronald