UNIX Bash vraagje: variablen uitlezen van een ander bestand

[Sonic]

Hallo allemaal.

Ik heb de volgende vraag. Ik wil een bash script maken waar ik een ander script mee uitvoer inclusief de parameters die daarbij horen. Het script komt er zo uit te zien:

. /<locatie script>/scriptnaam.sh <parameter 1> <parameter 2>

Nu wil ik alleen de <locatie script> uit een ander bestand halen. Het gaan namelijk allemaal losse bestanden worden om een job uit te kunnen voeren. Mocht de locatie een keer aangepast worden hoef ik het maar 1x te wijzigen naar de nieuwe locatie.

Dus zou ik zo iets kunnen maken?

$locatie = loactie.sh
. /$locatie/scriptnaam.sh <parameter 1> <parameter 2>

In het bestand locatie.sh staat dan bijvoorbeeld de regel:
/opt/usr/files

Ik hoop dat jullie me kunnen helpen

[DataGhost]

Je had het natuurlijk ook even kunnen proberen, niet? Ik zal je verder een hint geven: ja, dat kan. De syntax is echter een klein beetje anders als je de inhoud van het bestand wilt hebben, dus je zal de backtick-operator nodig hebben.

[ Voor 40% gewijzigd door DataGhost op 08-06-2008 15:43 ]

[Ivo]

in het geval van de backtick-operator zul je van je locatie.sh een script moeten maken dat de locatie retourneert. Dus bijvoorbeeld:

code:

echo "/opt/user/files"

En dan aanroepen met:

code:

`locatie.sh`/scriptnaam.sh

[Sonic]

Ah ik zat dus in de goede richting! Bedankt!

Ik had het graag zelf willen uitproberen, maar het is een server van me werk. En helaas heb ik hier (nog) geen eigen unix server staan. Ik was al wat dingen van te voren aan het uitzoeken. Nogmaals bedankt!

[Sonic]

Helaas het werkt nog niet helemaal...

Ik heb nu het volgende:
l_script.sh
echo "/opt/finance/script"

l_jobs.sh
echo "/opt/productie/week"

l_mail.sh
echo "[e-mail]"

Deze bestanden probeer ik met het volgende script aan te roepen:

test.sh
. /'l_script.sh'/batch.sh 'l_jobs.sh'/jobnaam.extentie 'l_mail.sh'

De foutmelding die ik terug krijg is de volgende:
./test.sh[4]: /l_script.sh/batch.sh: not found.

Hieruit maak ik op dat hij het script l_script.sh niet uitvoerd. Hier zou het path
opt/finance/script uit moeten komen, maar hij pakt het niet goed op.

[Anoniem: 76181]

Je moet ook back-quootjes gebruiken in plaats van enkele quootjes. Back-quootjes zitten links van de 1 op een US international toetsenbord. Je kunt ook $(l_script.sh) doen.


. /'l_script.sh'/batch.sh 'l_jobs.sh'/jobnaam.extentie 'l_mail.sh'

moet worden:
. /`l_script.sh`/batch.sh `l_jobs.sh`/jobnaam.extentie `l_mail.sh`

Persoonlijk zou ik het anders doen, namelijk een variabelen.sh maken die eruit ziet als:

code:

export script_lok=/opt/finance/script
export job_lok=/opt/productie/week
export email=[e-mail]

en dan in je script doen:

code:

. variabelen.sh
. ${script_lok}/batch.sh ${job_lok}/jobnaam.extentie $email

[serhat]

Anoniem: 76181 schreef op dinsdag 10 juni 2008 @ 12:05:
...

code:

. variabelen.sh
. ${script_lok}/batch.sh ${job_lok}/jobnaam.extentie $email

Dit zou moeten werken.. de nette manier is echter om 'source' te gebruiken.. dit is zeg maar de equivalent van 'include' zoals we het in meerdere talen kennen..

Voorbeeld:

code:

#!/bin/bash

# A script that includes another script

source My_Other_Script.sh    # include is in $PATH
source /path/to/the/include/My_Other_Other_Script.sh   # explicit PATH

[Anoniem: 76181]

Op zich wel, maar "source" is typisch linux. Omdat ik veel met andere unix'en te maken heb, gebruik ik liever iets dat overal werkt... :-)

[deadinspace]

Anoniem: 76181 schreef op dinsdag 10 juni 2008 @ 16:42:
Op zich wel, maar "source" is typisch linux. Omdat ik veel met andere unix'en te maken heb, gebruik ik liever iets dat overal werkt... :-)

Dat is onzin; source is gewoon een bash built-in command en werkt dus altijd in bash, ongeacht het OS waar het op draait.

edit:
(Ik dacht dat MyroX de topicstarter was, maar dat is dus niet zo. De tekst hierna is dus niet gericht aan MyroX, maar aan de topicstarter.)

En aangezien je het in je topictitel specifiek over bash hebt is het dus een prima antwoord.

Ik raad je trouwens aan om je een beetje in te lezen over bash scripting, (environment) variables, en command substitution. Hier zijn best wel introducties over te vinden.

En als ik dan toch aan het zeiken ben, gebruik alsjeblieft nooit backticks (``), maar in plaats daarvan $().

[ Voor 9% gewijzigd door deadinspace op 11-06-2008 13:05 ]

[Anoniem: 57996]

deadinspace schreef op dinsdag 10 juni 2008 @ 18:31:
[...]

Dat is onzin; source is gewoon een bash built-in command en werkt dus altijd in bash, ongeacht het OS waar het op draait.

En aangezien je het in je topictitel specifiek over bash hebt is het dus een prima antwoord.

Ik raad je trouwens aan om je een beetje in te lezen over bash scripting, (environment) variables, en command substitution. Hier zijn best wel introducties over te vinden.

En als ik dan toch aan het zeiken ben, gebruik alsjeblieft nooit backticks (``), maar in plaats daarvan $().

Wat jij zegt is ook onzin. Bash werkt wel maar is niet standaard geinstalleerd op de meeste unices. Als je het shellscript op elke bourne sh kloon wilt draaien moet je geen "source" gebruiken.

[RemcoDelft]

Wat denk je van zoiets:

./"`cat /tmp/file_met_locatienaam`"/scriptnaam.sh <parameter 1> <parameter 2>

Hierbij vervangt bash `cat filetje` door de naam in dat filetje (wel zorgen dat er maar 1 naam in staat in dit geval) en dat zou moeten werken. Zelf even testen

[ Voor 9% gewijzigd door RemcoDelft op 10-06-2008 22:06 ]

[deadinspace]

Anoniem: 57996 schreef op dinsdag 10 juni 2008 @ 21:03:
Wat jij zegt is ook onzin.

Wat ik zeg is volledig correct. source is een bash built-in command, en werkt dus altijd in bash.

Bash werkt wel maar is niet standaard geinstalleerd op de meeste unices.

De topictitel is "UNIX Bash vraagje: variablen uitlezen van een ander bestand". Het gaat dus specifiek over bash (zoals ik ook al aanhaal in mijn vorige post).

[Anoniem: 57996]

deadinspace schreef op dinsdag 10 juni 2008 @ 21:30:
[...]

Wat ik zeg is volledig correct. source is een bash built-in command, en werkt dus altijd in bash.

[...]

De topictitel is "UNIX Bash vraagje: variablen uitlezen van een ander bestand". Het gaat dus specifiek over bash (zoals ik ook al aanhaal in mijn vorige post).

Dat neemt niet weg dat source NIET werkt in andere bourne sh clones en dus wat MyRox zegt gewoon correct is.

[zomertje]

Op een standaard AIX vind je geen bash shell, dat is wat ie probeert duidelijk te maken.

Verder gebruik ik meestal variablen aan het begin van een script of gewoon in je .profile en je kan ze zelfs vastleggen voor alle gebruikers of voor gebruikersgroepen op Unix

Ik vraag me altijd af wat het doel is van hetgeen je aan het maken bent, dat is vaak bepalend hoe je het maakt.

[luteijn]

Het meningsverschil tussen deadinspace, flupzor en MyroX is natuurlijk geneuzel in de marge maar deadinspace heeft m.i. gewoon gelijk, Serhat's antwoord is prima. Sonic (de TS) schreef toch echt twee keer expliciet BASH; zowel in de titel van de topic als in de vraag zelf:

Sonic schreef op zondag 08 juni 2008 @ 15:39:
Ik heb de volgende vraag. Ik wil een bash script maken waar ik een ander script mee uitvoer inclusief de parameters die daarbij horen.

Ik neem aan dat de punt in de code blokjes van MyroX (da's dus NIET de TS) gewoon moet lezen als alternatieve schrijfwijze van 'source', wat Serhat dan wat leesbaarder opschrijft.
Uit een manpage van bash:

      .  filename [arguments]
     source filename [arguments]
          Read  and execute commands from filename in the current
          shell environment and return the  exit  status  of  the
          last  command executed from filename. ...

Als het dan in andere bourne-shells dan bash moet gaan werken, waarom gebruikt je dan weer wel de 'export aap=noot' syntax?

$ bash
bash-3.00$ export aap=noot
bash-3.00$ exit
$ export aap=boom
aap=boom: is not an identifier
$ aap=boom; export aap
$ sh
$ echo $aap
boom
$ exit 
$ . aap.sh
aap.sh: not found
$ . ./aap.sh
AAP=BOOM: is not an identifier

En waarom geen ./ (of ander path) voor 'variabelen.sh'? en waarom source je het uiteindelijke script als je al je variabelen net heb staan exporteren naar je environment?

Als die punt daar alleen maar stond als bullet ofzo, dan werkt het helemaal niet, want je parent process kan jouw environment helemaal niet zien, dus al die fijne exports doen helemaal niets.

Anyway het wordt een beetje een rant zo, dat schiet ook niet op, dus laat verder maar.

Weer wat terug naar het topic:
Ik doe zelf meestal een check of een bepaalde variabele al in de environment staat (opdat een gebruiker de default kan overriden) en zo niet, dan zet ik hem op de default (die dan meestal in een soort constanten blok bovenin het script wordt gedefinieerd, maar inderdaad ook gesourced (maar waar vandaan dan weer... zo blijf je bezig) kan worden. Backticks (en varianten) zijn handig maar niet altijd even foutenbestendig. Voor een onelinertje prima, als het script nog een tijdje mee moet, zijn er vaak mooiere oplossingen. Verder kan je maar beter helemaal geen aannames doen over het PATH van de gebruiker en/of de locatie van 'standaard' utilities als grep/awk/sed...

Pieter.

[Anoniem: 76181]

Wow, heftige reacties...

Beetje te heftig volgens mij, want ik merkte alleen maar op dat de verkeerde quootjes gebruikt werden, en ik gaf een alternatief om niet voor elke variabele een andere file te hoeven maken.

Maarrrrr, om even in te gaan op wat opmerkingen:

de punt voor ". variabelen.sh" staat er omdat dan variabelen.sh in de current shell word uitgevoerd, en niet een een subshell. Als je die punt weg zou laten zou het in een subshell uitgevoerd worden, en zodra hij dan weer terugkeert naar het originele script ben je de variabelen weer kwijt.

De manier die ik melde is geen alternatief op "source", het is een oude manier. Kennelijk vonden de Linux mensen dat niet overzichtelijk genoeg, en hebben ze "source" verzonnen. Ik moet zeggen dat source het wel ietsje overzichtelijker maakt, dus is het gewoon een vooruitgang. Maar het is nooit verkeerd om de door mij genoemde manier te kennen, omdat je nooit weet welke shells je in je leven tegen gaat komen.

De opmerking om nooit `` te gebruiken maar $() begrijp ik niet echt. Voor zover ik weet doet het hetzelfde, maar mocht ik het fout hebben, hoor ik het graag! :-)

De reden dat ik geen path heb staan voor variabelen.sh is dat ik er vanuit ga dat iemand die een script maakt wel begrijpt dat het dan in dezeflde directory moet staan, of de lokatie aangepast moet worden.

"export aap=boom" werkt in sh, ksh en bash.

Maar de opmerking dat het om bash gaat is volledig correct. Dit is uiteindelijk een topic geworden met vele oplossingen voor een klein probleempje! ;-)

[deadinspace]

Anoniem: 76181 schreef op woensdag 11 juni 2008 @ 11:11:
Wow, heftige reacties...

Sorry, ik was een beetje humeurig toen in mijn eerste post in dit topic plaatste, ik had het inderdaad wat vriendelijker kunnen brengen

De manier die ik melde is geen alternatief op "source", het is een oude manier. Kennelijk vonden de Linux mensen dat niet overzichtelijk genoeg, en hebben ze "source" verzonnen.

Niet Linux mensen, bash mensen! Dat was nou net het hele punt van mijn reactie op jou

De opmerking om nooit `` te gebruiken maar $() begrijp ik niet echt. Voor zover ik weet doet het hetzelfde, maar mocht ik het fout hebben, hoor ik het graag! :-)

Ja, ze doen inderdaad hetzelfde, maar:

• $() is duidelijk een speciale shell constructie, alles wat met $ begint is dat namelijk. Bij `` zou je instinctief denken aan quoting, maar het is iets heel anders. (principle of least surprise enzo)
• Backticks zijn vaak lastig te onderscheiden van apostrophes (zie Sonics derde post hier)
• $() is veel netter te nesten, vergelijk:
  

  DIR=`dirname \`which ls\``
  DIR=$(dirname $(which ls))

• \ heeft speciale betekenis binnen backticks, en niet binnen $(). Vergelijk:
  

  % echo `echo \\\\`
  \
  % echo $(echo \\\\)
  \\ 

Om die redenen raad ik altijd aan $() te gebruiken in plaats van ``.

[luteijn]

Toch leuk dat zo'n FAQ tot zo veel discussie leidt. Het allereerste antwoord was imho heel goed; gewoon een hint geven om persoon de goede kant op te schoppen, en dan maar wachten tot die het niet helemaal goed oppakt en er allerlei zijpaden bewandeld worden.

"export aap=boom" werkt in sh, ksh en bash.

Nee, werkt niet in sh, lees mijn vorige post nog even door. De commanduitvoer komt van een solaris machine.. Als je dit onder linux probeert, houd je jezelf voor de gek, doe maar eens ls -l /bin/sh... dat is onder linux normaal gesproken gewoon een link naar bash! En hoewel bash in dat geval een aantal nukken van de bourne shell overneemt, blijft het bash en kun je export aap=noot doen ipv eerst alleen de shell variabele te zetten en dan exporteren naar de environment..

nog even dit; in je eerste voorbeeld doe je niet alleen een 'source' van het variabelen.sh script, maar 'source' je ook het doel-script; dat is meestal niet slim (hint: shebang), en alle 'moeite' die je deed om de variabelen naar de environment te exporteren is dan ook overbodig.

P. (korn-shell gebruiker)

[Anoniem: 76181]

Met de sh van AIX kan ik gewoon "export aap=boom" doen. Mijn solaris machientje thuis staat momenteel uit, dus kan ik niet bekijken wat nu het verschil is tussen de sh van AIX en die van Solaris...
Op AIX:

code:

$ ls -l /usr/bin/sh
-r-xr-xr-x   5 bin      bin          237420 Jul 06 2006  /usr/bin/sh
$ /usr/bin/sh
$ echo $$
20857336
$ ps -ef | grep 20857336
XXXX   336112 20857336   0 09:37:13  pts/4  0:00 grep 20857336
XXXX 48402444 20857336   4 09:37:13  pts/4  0:00 ps -ef
XXXX 20857336 49635448   0 09:37:05  pts/4  0:00 /usr/bin/sh
$ export aap=boom
$ echo $aap
boom
$

Die export was misschien overbodig, maar ik ken het doel-script niet. Misschien worden in dat script wel weer andere scripts aangeroepen die ook de variabelen nodig hebben. Ik exporteerde die variabelen zodat in dat geval de TS niet weer tegen problemen op loopt.

[Anoniem: 76181]

Ik zie het al:

code:

$ ls -i /usr/bin/sh
 1028 /usr/bin/sh
$ ls -i /usr/bin/ksh
 1028 /usr/bin/ksh

Bij AIX is ie kennelijk ge-hard-linked.

[deadinspace]

luteijn schreef op donderdag 12 juni 2008 @ 09:32:

"export aap=boom" werkt in sh, ksh en bash.

Nee, werkt niet in sh, lees mijn vorige post nog even door. De commanduitvoer komt van een solaris machine..

Uit SUSv2:

SYNOPSIS

export name[=word]...
export -p

Dus dat ligt meer aan Solaris' sh dan aan iets anders

[luteijn]

los van of Solaris of AIX of HPUX of linux of IRIX of Minix etc. nou het gaarst zijn:

stelling: 'export aap=noot' werkt voor alle sh.
observatie: onder /bin/sh op een Solaris box werkt het niet.
conclusie: stelling is niet correct.


Overigens, (die) AIX (box) heeft geen (welllicht andere) sh in /bin ? Wat raar.

P.

[Anoniem: 76181]

luteijn schreef op donderdag 12 juni 2008 @ 12:16:
Overigens, (die) AIX (box) heeft geen (welllicht andere) sh in /bin ? Wat raar.

Dat is iets AIX-igs....

code:

$ ls -ld /bin
lrwxrwxrwx   1 bin      bin               8 Nov 29 2006  /bin -> /usr/bin

[luteijn]

Uit een de ksh manual van een of andere AIX versie:

The Korn shell is backwardly compatible with the Bourne shell (invoked with the bsh command) and contains most of the Bourne shell features as well as several of the best features of the C shell.

Probeer eens of je een bsh hebt, en wat die doet met "export noot=roos"?

P.

[blorf]

Dus zou ik zo iets kunnen maken?

$locatie = loactie.sh
. /$locatie/scriptnaam.sh <parameter 1> <parameter 2>

Je 1e regel is fout.
Bij een toewijzing van een variabele geen $-teken gebruiken voor zover ik weet.

ik heb niet alles hierboven gelezen, geen zin in shell-variant discussie, maar volgens mij wil je zoiets:

locatie=$(cat locatie.conf)

De variabele $locatie krijgt dan de inhoud van locatie.conf als waarde

of anders:

voorbeeldbestand locatie.sh:
#!/usr/bin/bash
echo "/pad/dir/map/locatie"

voorbeeldscript:
#!/usr/bin/bash

locatie=$(locatie.sh)

Hier is locatie.sh ook een script maar das niet echt nodig.

[blorf]

Nu we toch bezig zijn, het is ook niet moeilijk om een configuratiebestand voor verschillende variabelen te gebruiken:

voorbeeld config. bestand mijnscript.conf

tekst=blablabla
map=/usr/home/dir
pi=3,1415927

mijnscript.sh

#!/usr/bin/bash
#config variabelen inlezen
source ./mijnscript.conf

Het bestand mijnscript.conf wordt dan gewoon uitgevoerd als zijnde een stuk van mijnscript.sh
De variabelen zijn weer weg als het script is gestopt.
Het conf bestand moet wel uitvoerbaar zijn (chmod u+x)

[jschot]

blorf schreef op vrijdag 11 juli 2008 @ 14:44:
Nu we toch bezig zijn, het is ook niet moeilijk om een configuratiebestand voor verschillende variabelen te gebruiken:

...

Het conf bestand moet wel uitvoerbaar zijn (chmod u+x)

Dit is een goede tip. Maar het config bestand hoeft helemaal niet uitvoerbaar te zijn.