Ændring af PATH..?

[Jakob77]

Det er ikke testet fra min side, men her er lidt mere angående ændring af PATH:

http://user.it.uu.se/~matkin/documents/shell/#path

Citat:

Example: If your path contains `/usr/bin:/bin:/usr/local/bin' you may extend the path with /home/matkin/bin (which could be the place where you put your own scripts) by writing

Kode: Vælg alt

$ PATH=/home/matkin/bin:$PATH

The effect of this only remains as long as you are logged in.

[ChrisBuchholz]

Der står da vidst ikke noget du ikke har fået afvide tidligere?

[Jakob77]

Der står da vidst ikke noget du ikke har fået afvide tidligere?

Så vidt jeg husker kom du med denne udmærkede syntaks som eksempel:

Kode: Vælg alt

export PATH=$PATH:~/Dokumenter/kommandofiler

Nu har vi også denne:

Kode: Vælg alt

PATH=/home/matkin/bin:$PATH

For mig rejser det selvfølgelig spørgsmålet om, hvorfor man skal bruge "eksport"

Men derudover tror jeg, at det afklarer spørgsmålet om, hvordan man får en bestemt mappe til at stå allerførst i PATH'en.
Den første løsning anbringer den tilføjede mappe sidst, hvorimod den sidste løsning anbringer den allerførst, så Ubuntu straks finder den.

Sådan går jeg i hvert fald ud fra, at det hænger sammen, indtil det modsatte bliver bevist.


Men det er jo kun en opfølgning på tråden, min løsning går foreløbigt ud på at bruge den omtalte mappe, som der i forvejen er PATH til.

[Jakob77]

Vi kan altid blive ved med at pine noget mere ud af et emne, og dette er ingen undtagelse, så jeg genåbner hermed sudiekredsen for alle PATH-interesserede.



Man skulle måske tro, at det hele var med, når man kan tilføje en mappe til PATH'en ved enten at lægge den først eller sidst.

Men der er jo også mulighed for at lægge den i midten, og det er sikkert det sværeste og selvfølgelig nok typisk, hvad jeg netop gerne vil.

Hvis det er, som jeg formoder (ret mig, hvis jeg tager fejl), så søger Ubuntu efter filer i den rækkefølge, som mapperne står i PATH'en:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Den første mappe (/usr/local/sbin) er en systemmappe, og selvom jeg gerne vil have, at mine filer (scripts) bliver fundet hurtigt, så vil det være uforsigtigt og arrogant at sætte en mappe med mine egne hjemmefuskede scripts foran den mappe.

Den næste mappe (/usr/local/bin) er den mappe, som jeg bruger nu, og det må jeg vist godt.
Men jeg har den ikke for mig selv. Der kan komme programmer som kaster filer i den mappe, og de kan komme til at konflikte med mine scripts.

Derfor tror jeg måske, at det klogeste bliver at indføje en ny mappe, som ligger nøjagtigt imellem de to nævnte i PATH'en.


PATH=/usr/local/sbin:/Dokumenter/kommandofiler:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games


Men hvordan..?

Eller hvad har jeg overset..?

[laoshi]

For mig rejser det selvfølgelig spørgsmålet om, hvorfor man skal bruge "eksport"

Det skal du for at få din ændrede PATH til at gælde også uden for den aktuelle terminalsession. Det er lidt lige som med dine bash_aliases. Sætter du en alias i terminalen, så gælder den for den aktuelle session. Skal den gælde længere, så skal den eksporteres til .bash_aliases som så skal genindlæses.

[lath]

Vi kan altid blive ved med at pine noget mere ud af et emne, og dette er ingen undtagelse, så jeg genåbner hermed sudiekredsen for alle PATH-interesserede.



Man skulle måske tro, at det hele var med, når man kan tilføje en mappe til PATH'en ved enten at lægge den først eller sidst.

Men der er jo også mulighed for at lægge den i midten, og det er sikkert det sværeste og selvfølgelig nok typisk, hvad jeg netop gerne vil.

Det er rigtig god stil at tilføje stier til sidst i PATH. Årsagen er at hvis du kommer til at skygge for et vigtigt systemprogram, kan kun en Ubuntu Live system fra en CDROM eller en flash redde dit system fra en total reinstallation.

Hvis det er, som jeg formoder (ret mig, hvis jeg tager fejl), så søger Ubuntu efter filer i den rækkefølge, som mapperne står i PATH'en:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Det er rigtigt! Systemet søger efter programmer (binære+scripts) i den rækkefølge som PATH angiver.

Den første mappe (/usr/local/sbin) er en systemmappe, og selvom jeg gerne vil have, at mine filer (scripts) bliver fundet hurtigt, så vil det være uforsigtigt og arrogant at sætte en mappe med mine egne hjemmefuskede scripts foran den mappe.

Den næste mappe (/usr/local/bin) er den mappe, som jeg bruger nu, og det må jeg vist godt.
Men jeg har den ikke for mig selv. Der kan komme programmer som kaster filer i den mappe, og de kan komme til at konflikte med mine scripts.

Derfor tror jeg måske, at det klogeste bliver at indføje en ny mappe, som ligger nøjagtigt imellem de to nævnte i PATH'en.

Jeg synes som sagt at det er en meget dårlig ide. Kom ikke og sig du ikke var advaret. Lav hellere en bunke shortcuts fra Skrivebordet, eventuelt kan shortcutsene ligge i en mappe på Skrivebordet.

PATH=/usr/local/sbin:/Dokumenter/kommandofiler:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Forkert path! i

/Dokumenter/kommandofiler

har du glemt din hjemme mappe. Du mener sikkert

Kode: Vælg alt

$HOME/Dokumenter/kommandofiler

skriver du f.eks:

Kode: Vælg alt

PATH=$PATH:$HOME/bin

vil systemet - kigge i brugerens egen bin mappe effter programmer.

Brugeren er den der er logget ind på ethver givent tidspunkt, så et script i bin vil ikke virke med sudo, da systemet vil kigge i /root/bin mappen, istedet for $HOME/bin, som for dit vedkommende kommer til at blive udvidet til /home/jacob/bin, gætter jeg ($HOME er /home/jacob for dig)

Test hvad $HOME er for dig således:

Kode: Vælg alt

echo $HOME

/Lars

[Jakob77]

lath

Mange tak for dit svar.

Din advarsel gør stort indtryk, så hvis der skal være en permanent PATH til en mappe med private scripts, så bør den nok lægges sidst i strengen, selvom det er langsommere.

Men er det ikke normalt, at programmer ændrer midlertidigt på PATH'en så længe programmet kører..?
Og gør man dette via et script, som også kalder programmet, så kan det samme script bagefter sætte PATH'en tilbage igen.
Gør man det på den måde, så vil maskinen altid have den originale path efter boot-op, og så kan man vel undgå det problem, som du beskriver..?

Så, hvordan omstiller man PATH'en midlertidigt via et script..?



Hvad er forskellen mon på disse to kommandoer:

Kode: Vælg alt

export PATH=$PATH:~/Dokumenter/kommandofiler


export PATH=$PATH:$HOME/Dokumenter/kommandofiler

Som jeg forstår dig skal et hjemmefusket script lægges helt ude i roden, hvis man skal kunne kalde det med "sudo " (superbrugerrettigheder) foran, ellers bliver det ikke fundet uanset PATH'en.
Men jeg ved, at "sudo" godt kan virke til visse kommandoer inde i et script, og så må man vel altid kunne klare sig med at lade et script kalde et script..?

[ChrisBuchholz]

Det er selvfølgelig muligt at smide din egen path-mappe foran i path når programmet starter, og så derefter sætte det tilbage til normal når programmet er færdig med at køre, men jeg synes det er en rigtig dum idé.

1) hvorfor? Hvorfor dog lave sådan nogen krumspring? Hvorfor ikke bare lave en variabel der indeholder "~/Dokumenter/kommandofiler" og så kalde dine scripts med $path_var/navn_på_script.sh?
2) at gå ind og ændre sådan på path er en rigtig dum sport at komme igen med, især når det ikke er en langvarig ændring.

for at besvare dit spørgsmål dog, er løsningen på dit problem med den midlertidige ændring af path, noget i denne her stil (giver ihvertfald stuff til eftertanke):

Kode: Vælg alt

path_orig = $PATH

export PATH=$HOME/Dokumenter/kommandofiler:$PATH

# do something something...
# nu er vi færdige og sætter path tilbage til originalen

export PATH=$path_orig

[Jakob77]

Det er selvfølgelig muligt at smide din egen path-mappe foran i path når programmet starter, og så derefter sætte det tilbage til normal når programmet er færdig med at køre, men jeg synes det er en rigtig dum idé.

1) hvorfor? Hvorfor dog lave sådan nogen krumspring? Hvorfor ikke bare lave en variabel der indeholder "~/Dokumenter/kommandofiler" og så kalde dine scripts med $path_var/navn_på_script.sh?
2) at gå ind og ændre sådan på path er en rigtig dum sport at komme igen med, især når det ikke er en langvarig ændring.

for at besvare dit spørgsmål dog, er løsningen på dit problem med den midlertidige ændring af path, noget i denne her stil (giver ihvertfald stuff til eftertanke):

Kode: Vælg alt

path_orig = $PATH

export PATH=$HOME/Dokumenter/kommandofiler:$PATH

# do something something...
# nu er vi færdige og sætter path tilbage til originalen

export PATH=$path_orig

Du er ikke bange for at ryste en stump kode ud af ærmet, og det ser endda ud til at virke, så rigtig mange tak for det.

Det er også helt fint med mig, at jeg afkræves begrundelser.
Man kan gøre så mange ting, som umiddelbart virker smart, men når man så fordyber sig lidt mere, så finder man ud af, at det alligevel ikke er nødvendigt. Derfor er det altid sundt at diskutere det på en god måde, før man gør alt for mange omstændige ting.


Men jeg er nok ved at nå frem til, at hvis der i det hele taget skal ændres på originalPATH'en, så skal det helst gøres via et sådant script, som jeg kan undlade at køre, når Ubuntu booter op.
Der må vel f.eks. være en simpel metode, så man i bootopfasen kan undgå at køre de filer, som man har lagt ind i System > Indstillinger > Sessioner.
Derved kan man sikre, at PATH'en til de uartige hjemmefuskede scripts bliver afbrudt.
Det sikrer selvfølgelig ikke mod, at et script stadig kan kaldes med "full qualified path", hedder det vist. Altså hvis hele adressen til scriptet angives i kaldet fra prompten.

F.eks. i denne stil:

$HOME/Dokumenter/Kommandofiler/jakobs_totale_ødelæggelses_script.sh

Gør man sådan, så mener jeg, at det må kunne gennemtvinge en kørsel uanset, hvordan PATH er sat i systemet, og det giver endda en meget hurtig response, fordi Ubuntu ikke behøver at søge efter filen, men kan gå direkte til den.
Det kan man gøre fra terminalprompten eller man kan gøre det i et script, og på den måde mener jeg også, at man kan få "sudo" til at virke på et script, selvom det ikke ligger i roden. Man skal bare lige kende problematikken (tak til Lars).


Altså på denne måde:

sudo $HOME/Dokumenter/Kommandofiler/jakobs_totale_ødelæggelses_script.sh

Eller du foretrækker måske denne version, som ser ud til at gøre det samme:

sudo ~/Dokumenter/Kommandofiler/jakobs_totale_ødelæggelses_script.sh



En anden fordel ved at ændre PATH via et privat script kan være, at man ikke behøver at rette i ~/.bashrc , man kan bare køre sit script, og ding dong, så er det ordnet, også på en helt ny installation.


Endelig var der min begrundelse om at visse programmer har brug for at ændre PATH midlertidigt.
Det ved jeg ikke helt sikkert, om er tilfældet i Linux, og jeg søger en bekræftelse.
I DOS husker jeg f.eks., at det kunne være en fordel at have en midlertidig PATH til Norton Commander, hvis den ikke skulle smide "nc.ini"-filer i alle mulige mapper.
Men når programmet afsluttes, så er det en fordel, at der ikke længere er PATH til mappen, da det forkorter søgetiden i PATH'en og reducerer risikoen for dubletter, at der er færre mapper.

Så alt ialt mener jeg da godt, at der kan være meget gode argumenter for at stable sådan et script på benene.
Men som det nok fremgår, så ved jeg ikke særlig meget om Linux endnu, og der kan sagtens være nogle vigtige parametre, som jeg ikke kender.



Testscriptet lægges her til kritik:

Kode: Vælg alt

#!/bin/bash
#Grundstammen i dette script er skaffet til veje via Ubuntu-Danmark.dk https://ubuntudanmark.dk/forum/viewtopic.php?p=40194#p40194
#Filens formål er at ændre path midlertidigt, mens et program køres.
#Sættes den sidste kommando ud af kraft, så stilles PATH ikke automatisk tilbage, før efter næste boot.
#
path_orig = $PATH
#
#nedenstående linje er en form for "debug", som jeg har lært af Laoshi til prøvekørsel.  :-)
set -x
#
export PATH=$HOME/Dokumenter/kommandofiler:$PATH
#
#nedenstående linje sender output fra "set" til filen testres.ult, hvor jeg så efterfølgende kan læse, hvad PATH er på dette sted
#set > $HOME/Menu/testres.ult
#
# do something something...
# nu er vi færdige og sætter path tilbage til originalen
export PATH=$path_orig

[ChrisBuchholz]

@Jakob77:

Ja, jeg tror ikke at det kan skade at ændre path'n midlertidigt mens programmet køre, hvis man bare husker at sætte den tilbage. Jeg kan dog stadigvæk ikke se et argument for dette.

Som jeg nævnte, så er der intet i hindring for at gøre sådan her:

Kode: Vælg alt

myPATH = /fuld/sti/til/kommandofiler

# så kalder vi en fil
bash $myPATH/en_fil.sh

# så kalder vi en til
python $myPATH/en_anden_fil.py

Jeg kan ikke se hvad du vil vinde i midlertidigt at ændre path overhovedet, andet end selvfølgelig risikere at kludre alting sammen, da der jo intet er i vejen for at lige efter at du gemmer den originale path i en variabel, og inden du smider den originale path tilbage i path, så smutter der lige et program ind og tilføjer en mappe til path, som faktisk skal bruges til noget. Når du så genopretter den originale path, så får du ikke den mappe med som blev tilføjet mens dit script kørte.
Dette undgår du med min metode.

[Jakob77]

#Sættes den sidste kommando ud af kraft, så stilles PATH ikke automatisk tilbage, før efter næste boot.
#

Sikke noget sludder at skrive, jeg synes, at det nu ser ud til, at den i stedet laver en cookie .....

[Jakob77]

Som jeg nævnte, så er der intet i hindring for at gøre sådan her:

Kode: Vælg alt

myPATH = /fuld/sti/til/kommandofiler

# så kalder vi en fil
bash $myPATH/en_fil.sh

# så kalder vi en til
python $myPATH/en_anden_fil.py

Så vidt jeg kan se, er det et vældig smart trick til at forkorte en lang sti. Men ellers gør det jo ikke noget, som ligner en ændring af PATH
Så skulle jeg da ligefrem kalde variablen for f.eks. "/usr/local/bin", men det kan jeg vist ikke, og det ville også være noget rod.

alias er måske et endnu bedre forslag, men stadig ikke den ægte vare.

Jeg kan ikke se hvad du vil vinde i midlertidigt at ændre path overhovedet, andet end selvfølgelig risikere at kludre alting sammen, da der jo intet er i vejen for at lige efter at du gemmer den originale path i en variabel, og inden du smider den originale path tilbage i path, så smutter der lige et program ind og tilføjer en mappe til path, som faktisk skal bruges til noget. Når du så genopretter den originale path, så får du ikke den mappe med som blev tilføjet mens dit script kørte.

Av av, den risiko havde jeg ikke overvejet. Se bare, hvor godt det er at få det diskuteret.
For det må jo nok om ikke andet være en teoretisk risiko, når der samtidigt åbnes mange forskellige programmer.

Når flere programmer skal deles om det samme system, så må der være brug for nogle konventioner, så de ikke tørner sammen og ødelægger det for hinanden.
Derfor forestiller jeg mig, at der må være et sted, hvor man kan se hvilke variabler alverdens Linux-programmer har valgt, så man har en mulighed for at træffe et sikkert valg.
På en sådan liste må man også kunne se, om de bruger dem til at ændre PATH.

Det kan godt være, at jeg drømmer, og at det i virkeligheden er en værre rodebutik, men jeg fortsætter i samme håbefulde tro:

På en tilsvarende liste vil jeg hermed gerne reservere mappenavnet "~/Menu" og mappenavnet "~/bin" og en PATH til sidstnævnte mappe med tilhørende variabelnavn "$mpstore" til lagring af originalPATH'en.
Og angående filer i PATH'en , så vil jeg hermed gerne reservere "menu.sh", "menu", "ged.sh" og "ged"


Hvor findes disse reservationslister for programudviklere..?

Hvis ikke de findes, så må det måske være nok med en offentliggørelse som denne, og kommer der så senere nogen på tværs, så er det deres fejl.


Det løser dog ikke problemet.
Hvis jeg skal værne en midlertidig PATH-ændring imod den risiko, som du nævner, så må det som minimum nok kræve, at jeg kender andre programmers adfærd på området.

Dette taler måske så slutteligt for at lægge PATH-ændringen lige efter bootop og så ikke pille mere senere.
Min undersøgelse her snører sig også mere og mere sammen om, at jeg må insistere på at få en mappe for mig selv, som der er PATH til. Ellers får jeg aldrig rigtig orden i butikken.

[ChrisBuchholz]

@Jakob77:

Gør sådan her og problemet er løst:

Kode: Vælg alt

P = /sti/til/kommandofiler

Hvis du kigger efter så giver dette faktisk en endnu kortere variabel at arbejde med - her har du $P og før havde du $PATH.
Jeg kan overhovedet ikke se hvorfor du vil ind og ændre path. Meningen med path er at man kan fyre ting af, man ikke nødvendigvis ved hvor ligger (tænk bare hvis du skulle kende stien til alle de bash kommandoer du bruger), samt at gøre det hurtigere at manøvre rundt i tingene live. Det er ikke meningen at developers skal voldtage path, fordi de gerne vil spare én enkelt linie i deres kode. Og ja, det er voldtægt at vil gøre det du vil der. Det er super unødvendigt, og skaber kun problemer.

Lav en variabel der indeholder den sti du skal bruge, og du er done. Problem's solved, og du kan komme videre med dine scripts.

[soundpartner]

Nu har jeg længe holdt mig tilbage fra denne og script tråden men nu kan jeg sgu ikke mere.
Jeg forstår virkelig ikke hvad det er du vil.
du vil lave en bunke scriptfiler således at nemmere kan tilgå forskellige ting fint fint den er jeg ed på, men at "omdøbe" f,eks firefox til ff det ser jeg ingen ide i. hvorfor såikke bare klikke på firefox iconet. nemmere bliver det sgu da ikke. hvorfor skal man ud i terminalen og køre ting?

med blandtandet tab-complete så er det super nemt at skrive længere komandoer f.eks giver fir[tab] firefox og sådan kan man jo blive ved. Fint fint det er så 4 tast og ikke 2 men stadig hvorfor?

faren ved dete her er at
1: andre fatter ikke hvad fanden du har gang i hvis de låner din maskine
2: når du nu har vænnet dig til at bruge kommandoer som ff, sn ffu eller hvad du nu kalder dine scripts så "glemmer" du hurtigt hvad de "rigtige" komandoer er og bliver derfor pludselig ude af sand til at bruge en andens maskine for DU har jo vedtaget at tingene ikke skal hede det de hedder men skal hede noget andet

i de gode gamle dos-dage der lavede jeg mange "bat-menuer" som var snedige på mange måder da det sparede mange tastetryk og man slap fpr at huske stier og komandoer til at starte sine programmer med de options man nu havde osv, men i dag der kan det jo fint klares grafisk med ikoner på skrivebordet, en dock eller lignende, og det er alt andet lignende en del nemmere end at rode i terminalen med små scriptfiler.

jeg kan forstå det hvis du sad på en server uden et gui og skulle starte tng og sager ofte
(bac= lav en komplet backup af hele maskinen. baw=lav en backup af webserveren osv) det er der scripts kommer til sin ret, men at lave et script til at starte firefox, så skal du først starte terminalen (hey det er lige så hurtigt at bare starte firefox med det samme) så skal du køre dit script som så skal tilbage i det grafiske og loade firefox med den rigtige startside for dig. men hvorfor ikke bare lave et tab-link til de 3 sider du ofte bruger?

endnu nemmere ville det være at lave nogle hotkeys (f,eks [alt][f] til firefox, [alt][w] til openoffice word osv)

at begynde at lave variabler til paths for at spare tastetryk i scripts osv det er sgu lidt at gå efter åen efter vand.
skal du lave dine egne scripts og have dem gemt et andet sted end standart path så lav en mappe, smid et link til mappen i slutningen af dine path's og så slipper du for at skrive stien til scriptet. hele diskussionen med at det "går for langsomt" hvis path'et er i slutningen ser jeg heller ikke som et problem. der er ikke tale om mange millisekunder (med mindre du selvfølgelig omber dine paths med alt muligt andet crap)

Det var lidt af en smørre fra min side og hvis du kan diske op med en god og gennemtænkt grund til dit lille projekt så tager jeg al min negativitet i mig igen. Det kunne jo være uvidenhed fra min side, men jeg syntes virkelig du går over åen,sætter dig ind i bilen for at køre til nabobyen for så at fylde din hullede spand med vand fra den samme å som du idligere passerede for at komme til bilen

[ChrisBuchholz]

Som en lille opfølger til Soundpartners indlæg, så kan jeg foreslå Do - http://do.davebsd.com/ - hvilket er en super nifty launcher. Jeg kan ikke forestille mig min desktop uden!

Som jeg har sat den op, så vækkes Do med et tryk på <Ctrl><Spacebar>, og så kan man ellers hurtigt smide diverse ting deri. Den husker de programmer du bruger mest, og hvis jeg bare skriver f.eks. "f" deri, så foreslår den allerede firefox, da det er den applikation jeg bruger mest der starter med f.
Udover det findes der også en helt masse andre ting end at launche man kan med Do. F.eks. kan jeg skrive "map nyborg, fyn, danmark" og så åbner den google map og finder Nyborg på Fyn i danmark. Alle sådan nogen ting er mulige i Do - super smart! Det er endda muligt at styre sin musikafspiller, oprette kalender-entries og alt muligt sjovt via Do, og hvis du får blod på tanden, kan man kan bare skrive sine egne plugins til Do, og så kan den endnu mere. Det er lidt ligesom Ubiquity til desktoppen.