Er ikke helt sikker på export og miljø variabler i Unix-like OS

Tags:    linux unix bash shell

<< < 123 > >>
Jeg er ikke helt sikker på miljøvariabler og export i Bash og andre shells. Tror jeg har forstået det - så her er min forklaring. True or false?

(Fra StackOverflow)
When you execute a program the child program inherits its environment variables from the parent. For instance if $HOME is set to /root in the parent then the child's $HOME variable is also set to /root.

This only applies to environment variable that are marked for export.


Okay, parent program i det her tilfælde er styresystemet? Også er child program de shells som bliver kørt? Og miljøvariabler er globale variabler som bliver brugt i ALLE childs/shells?

Hvis du bruger export når du ændre en miljøvariabel så ændres den globalt.. Hvis ikke, er det kun i den child/shell du har kørt ændringen i at det ændres. Hvilket vil sige at når du lukker den shell så er din ændring tabt for evigt og miljøvariablen er tilbage til at være det "default", eller hvad nu sidst "exporterede" den til at være? Har jeg ret?



21 svar postet i denne tråd vises herunder
7 indlæg har modtaget i alt 14 karma
Sorter efter stemmer Sorter efter dato

Okay, parent program i det her tilfælde er styresystemet?

Well...afhænger af definitionen. Når kernen er indlæst og initialiseret, så eksekverer det det første program, som kaldes 'init' (det har process id 1).
'init' eksekverer efterfølgende terminaler, som du kan logge ind på og få en shell. Så terminalerne får 'init's miljøvariable. De kan ændre dem, slette dem, tilføje. Din shell får så terminalens variable, men ændrer og tilføjer typisk en hel masse nye. Alle programmer, som du starter fra din shell har samme variable som din shell (men kan igen lave ændringer). Man kan ikke ændre miljøvariable for sin forældre proces...kun for sig selv, og man kan starte nye børne processer med ændrede variable.


Hvis du bruger export når du ændre en miljøvariabel så ændres den globalt.

Nej, ikke globalt men for din shell. En proces kan kun ændre miljøvariable for sig selv. Du kan starte et program med ændrede miljøvariable således:
Fold kodeboks ind/udKode 

Programmet 'my_program' bliver her kørt med alle din shells variable plus MY_VARIABLE.
Men MY_VARIABLE bliver ikke sat for din shell. Det vil den til gengæld her:
Fold kodeboks ind/udKode 



Hvis ikke, er det kun i den child/shell du har kørt ændringen i at det ændres. Hvilket vil sige at når du lukker den shell så er din ændring tabt for evigt og miljøvariablen er tilbage til at være det "default", eller hvad nu sidst "exporterede" den til at være? Har jeg ret?

Ja og nej...der er ikke noget som går tilbage til at være noget som det var tidligere. Hvis du ændrer miljø variable i din shell, så er det KUN i din shell, at de er ændrede...ikke i terminalen, som du loggede ind fra. Lukker du din shell, så dør ændringerne med din shell, men intet er ændret i terminalen, så hvis du logger ind igen, så får du en ny shell med de samme variable som terminalen har og hele tiden har haft.



Det er shell, der eksekvere programmer i UNIX (men programmer kan frigøre sig fra deres parent og blive en "daemon". Så når du eksekvere et program fra shell, "arver" den process, dens miljøvariabler.

Miljøvariabler bliver "loadet" og sat ved terminal-startup, og derfor (med mindre de er gemt) vil de også forsvinde eller tage deres default værdi ved genstart.

Derfor er det kotyme, at sætte/export'e miljøvariabler i din ~/.bashrc eller ~/.bash_profile




Daemon? DETAILS PREASE! Det er en process som ligger i baggrunden ikke? Lidt ligesom en Thread i Java og C#?

En daemon har ikke noget med threads at gøre, men det er som du siger en proces som ligger i baggrunden. Ligesom services i Windows.
Apache og cron er typiske eksempler på daemons...daemons har så ikke så meget med miljøvariable at gøre.


~/.bashrc eller ~/.bash_profile

Hvor finder jeg disse filer?

Det var den FULDE sti du fik, så lige dér :-)
'~' er synonym med dit hjemmebibliotek, så det er det samme som '$HOME'.
Filer som starter med et punktum er skjulte, men kan vises med 'ls -a'.


Så når man ikke bruger export ændres miljøvariablen kun i de processer som kører INDE i den shell man bruger lige nu (ville det ikke svare til "this" i java?)?

Yes (men jeg kan ikke helt se analogien med Java)...det er nok sjældent, at man bruger det. Jeg selv bruger det til at eksekvere programmer med en midlertidig LD_LIBRARY_PATH variabel, som fortæller lænkeren hvor den skal lede efter shared libraries.


Hvordan ændrer man så miljøvariabler globalt? Hvordan ændrer man $PATH til ALTID at kigge i f. eks /Home/home/Bin også?

Du kan tilføje dem til din egen .bashrc eller .bash_profile. Så findes de i DIN shell.
Eller du kan tilføje dem til /etc/bashrc, så er de i alles shell (men ikke i programmer som er startet uden en shell).


Hvad skal programmer bruger miljøvariabler til? Kan du/I komme med et eksempel.. - og kan "childs" ændre miljøvariabler på vegne af sig selv? Altså så de kun ændrer miljøvariablerne lokalt?

Programmer kan ændre deres egne miljøvariable.
Miljøvariable er input til programmer, så de kan bruges til alt det samme, som du ville bruge al anden input til.

F.eks. hvis dit program skriver til en fil, så kunne du give stien til filen på som et argument:
Fold kodeboks ind/udKode 

...eller som en miljøvariabel:
Fold kodeboks ind/udKode 


Det typiske er sikkert at bruge miljøvariable til information, som man sjældent ville ændre, men som man heller ikke vil hardcode direkte i programmet. Et alternativ til dette kunne være en konfigurationsfil.



Hvorfor er der nogle programmer som åbnes "inde" i en shell, mens der er andre som ikke åbnes med en shell?


Det ville være ret træls at arbejde sådan...du skulle selv starte apache, din grafiske brugerflade, cron, web browser, mail klient, musik afpiller, osv, osv.

Når du starter en browser via et klik på et ikon, så starter du jo ikke browseren fra en shell. Shellen er bare kommandolinjen og er helt klart et lækkert sted at arbejde fra, men nogle programmer er bare lidt mere naturlige at arbejde med med musen.

Og de fleste daemons skal startes automatisk (via init scripts som ligger i /etc/init.d).


Og alle de processer som bliver "styret" eller kører inde i en shell - hvor kan man se de shells? Kan man på nogen måde "åbne" dem mens programmet er åbent?

Jeg forstår ikke helt hvad du vil. Du kan se hele dit proces træ med 'ps axjf' og der kan du se, hvilke programmer som kører under 'bash'.



Indlæg senest redigeret d. 16.04.2013 12:48 af Bruger #2695

Okay, scriptet /etc/init.d bliver kørt... hvornår? Ved start-up eller ved login?

Der er flere scripts. De køres når din maskine startes og når den lukkes ned. De får argumentet 'start' eller 'stop' alt efter om maskinen starter op eller lukker ned.

Faktisk er det sandsynligvis ikke alle de scripts som kører. Når din maskine starter, så går det ind i et 'runlevel', som bestemmer hvilke scripts, som skal køre. Typisk starter du med runlevel 2, og dermed bliver scripts i /etc/rc2.d/ kørt. Runlevel 2 er typisk den "almindelige" runlevel og skal derfor for en desktop maskine starte en grafisk brugerflade og cron og netværk og alt muligt andet.

Er noget helt galt kan man bruge en anden runlevel som ikke starter en hel masse men bare giver dig en shell så du kan fejlfinde.


BTW - når jeg tjekker $PATH og kigger i nogle af de directories den giver mig, så ser jeg en masse scripts - de scripts man kan køre fra en shell, uden at skrive "bash" først og slutte filnavnet med ".sh". Jeg tjekkede hvilken slags filer det var, det er shell script - men x-shellscripts. Hvad er det? Hvordan kan man gøre en fil executable, så man KUN skal skrive filnavnet, uden extension og uden at bruge en kommando - udelukkende navnet?


Ok...jeg løj lidt før. Scripts bliver altid kørt under en kommandofortolker, og hvilken det er skal stå i første linje i filen:

Fold kodeboks ind/udKode 


Når jeg eksekverer et af de to scripts vil mit system sige "Det kan jeg ikke...men jeg kan eksekvere /bin/bash med statistics.sh som argument".

Man gør et script eksekverbar med 'chmod +x script.sh'
Så kan det eksekveres med './script.sh'.

Extension er ikke strengt nødvendigt, men når du eksekverer scriptet skal det være det fulde navn. De to ovenstående scripts kunne sagtens have heddet 'statistics' og 'vat_check'. Extensionen er for min egen skyld.



dot '.' er et synonym for 'source', der eksekvere et script.



Indlæg senest redigeret d. 16.04.2013 18:48 af Bruger #11328

dot '.' er et synonym for 'source', der eksekvere et script.

...dog med den vigtige tilføjelse at det er den NUVÆRENDE shell, som eksekverer. Dermed vil alle ændringer af miljøvariable og lignende slå igennem i din shell.

Det er forskelligt fra hvis du bare havde eksekveret scriptet normalt, for så ville der blive startet en ny shell, hvor ændringerne ville blive lavet, og den ville afslutte sammen med scriptet.



Det er shell, der eksekvere programmer i UNIX (men programmer kan frigøre sig fra deres parent og blive en "daemon". Så når du eksekvere et program fra shell, "arver" den process, dens miljøvariabler.

Miljøvariabler bliver "loadet" og sat ved terminal-startup, og derfor (med mindre de er gemt) vil de også forsvinde eller tage deres default værdi ved genstart.


Daemon? DETAILS PREASE! :D Det er en process som ligger i baggrunden ikke? Lidt ligesom en Thread i Java og C#?

~/.bashrc eller ~/.bash_profile

Hvor finder jeg disse filer? o.o

Nej, ikke globalt men for din shell. En proces kan kun ændre miljøvariable for sig selv.

Så når man ikke bruger export ændres miljøvariablen kun i de processer som kører INDE i den shell man bruger lige nu (ville det ikke svare til "this" i java?)?

Hvordan ændrer man så miljøvariabler globalt? Hvordan ændrer man $PATH til ALTID at kigge i f. eks /Home/home/Bin også?

Nej, ikke globalt men for din shell. En proces kan kun ændre miljøvariable for sig selv. Du kan starte et program med ændrede miljøvariable således:
Fold kodeboks ind/udKode 


Hvad skal programmer bruger miljøvariabler til? Kan du/I komme med et eksempel.. - og kan "childs" ændre miljøvariabler på vegne af sig selv? Altså så de kun ændrer miljøvariablerne lokalt?



Indlæg senest redigeret d. 16.04.2013 11:48 af Bruger #16945
Det var den FULDE sti du fik, så lige dér :-)


Ja, okay pinligt XD

- Hvorfor er der nogle programmer som åbnes "inde" i en shell, mens der er andre som ikke åbnes med en shell?

Og alle de processer som bliver "styret" eller kører inde i en shell - hvor kan man se de shells? Kan man på nogen måde "åbne" dem mens programmet er åbent?



Hvorfor er der nogle programmer som åbnes "inde" i en shell, mens der er andre som ikke åbnes med en shell?


Det ville være ret træls at arbejde sådan...du skulle selv starte apache, din grafiske brugerflade, cron, web browser, mail klient, musik afpiller, osv, osv.

Når du starter en browser via et klik på et ikon, så starter du jo ikke browseren fra en shell. Shellen er bare kommandolinjen og er helt klart et lækkert sted at arbejde fra, men nogle programmer er bare lidt mere naturlige at arbejde med med musen.

Og de fleste daemons skal startes automatisk (via init scripts som ligger i /etc/init.d).


Og alle de processer som bliver "styret" eller kører inde i en shell - hvor kan man se de shells? Kan man på nogen måde "åbne" dem mens programmet er åbent?

Jeg forstår ikke helt hvad du vil. Du kan se hele dit proces træ med 'ps axjf' og der kan du se, hvilke programmer som kører under 'bash'.


Nåååår, okay! Forstår bedre nu. Okay, scriptet /etc/init.d bliver kørt... hvornår? Ved start-up eller ved login?

BTW - når jeg tjekker $PATH og kigger i nogle af de directories den giver mig, så ser jeg en masse scripts - de scripts man kan køre fra en shell, uden at skrive "bash" først og slutte filnavnet med ".sh". Jeg tjekkede hvilken slags filer det var, det er shell script - men x-shellscripts. Hvad er det? Hvordan kan man gøre en fil executable, så man KUN skal skrive filnavnet, uden extension og uden at bruge en kommando - udelukkende navnet?



<< < 123 > >>
t