waarom ./ voor een run commanda

[Zym0tiC]

waarom moet je bij sommige commando's ./ ervoor doen ook al ben je in de directory zoals bij ./configure en wanneer / waarom niet

[ChiLLeR]

Als je in een directory iets wil executen gebruik je ./
staat het programma in je PATH dan geen ./

S-I-M-P-E-L

[SenZatioN]

Das nou een lekker duidelijk antwoord

[Sanjuro]

Als je een commando uitvoert op de Linux prompt dan zoekt het systeem in de directories in je PATH naar waar het programma staat. En niet zoals bij DOS eerst in de huidige directory en daarna pas in het PATH.

"./configure" betekent run de configure in de huidige directory.

Dit gedrag kan je aanpassen door de huidige dir (".") dus in je PATH op te nemen.

[Valium]

Omdat je huidige werkmap normaal gesproken niet in het pad staat. Je moet dat trouwens niet bij sommige commando's doen, maar bij ALLE commando's. Als je eens kijkt naar je omgevingsvariabelen (met "set"), dan zie je daar PATH=blabla staan. Programma's die daarin staan kun je zonder toevoeging starten.

Stel je hebt een pad: PATH=/usr/bin
Hetzelfde programma (bla) is geïnstalleerd in /usr/bin, /home/zymotic en /home/zymotic/usr/bin.

je staat in /home/zymotic.
Als je gewoon "bla" intikt, dan zal /usr/bin/bla gestart worden.
Als je ./bla intikt, dan zal /home/zymotic/bla gestart worden.
als je usr/bin/bla start, dan zal /home/zymotic/usr/bin/bla gestart worden.
Al je /usr/bin/bla start, dan zal /usr/bin/bla gestart worden.
Zo duidelijker? Of alleen maar verwarrender?

[Zym0tiC]

ik snap um helemaal thnx voor de reacties

[DeBolle]

Unix 'zoekt' alleen in het path naar uit te voeren commando's, terwijl dos/windows daarnaast ook de huidige dir doorzoekt.
In unix zul je dus altijd het volledige path naar een commando moeten opgeven als het niet in jouw path staat. Dat 'volledig' kan zowel absoluut (vanaf de root) als relatief (vanaf de huidige dir).
Als je nu in /usr/local/bin/mijneigenscripts staat en daar een script 'doehet' wil starten, kun je dus het volledige pad opgeven: '/usr/local/bin/meijneigenscripts/doehet' of relatief vanaf de huidige dir: './doehet'.
De './' is namelijk 'hier' ofwel in de huidige dir. Met twee '../' wordt een directory hoger bedoeld.
Als je dus in /usr/local/bin/mijneigenscripts staat en je wilt iets starten in /usr/local/bin/jouwrommel dan kun je gebruiken '../jouwrommel/doehet'

HTH

[RemcoX]

Op zaterdag 15 september 2001 17:01 schreef Sanjuro het volgende:
Dit gedrag kan je aanpassen door de huidige dir (".") dus in je PATH op te nemen.

Dit is dus HEEL ERG dom

Zo haal je de hele security onderuit, die door dit systeem was ontstaan. Het bekende voorbeeldje: Een user heeft in zijn home directory een shell scriptje staan met de naam 'ls', en erin 'rm -Rf /'.

Als je dan als root in die directory staat, en je doet ls, is je bak weg

[Sanjuro]

Op zaterdag 15 september 2001 17:36 schreef RemcoX het volgende:

[..]

Dit is dus HEEL ERG dom

Ik heb ook niet gezegd dat dat handig is in verband met de beveiliging van je systeem. Ik heb alleen maar een zo volledig mogelijk antwoord proberen te geven.

Bovendien hoeft het helemaal geen probleem te zijn. Je kan "." bijvoorbeeld achter in je PATH zetten, dat lost dit meteen ook weer op.

[RemcoX]

Op zaterdag 15 september 2001 17:44 schreef Sanjuro het volgende:

[..]

Ik heb ook niet gezegd dat dat handig is in verband met de beveiliging van je systeem. Ik heb alleen maar een zo volledig mogelijk antwoord proberen te geven.

Bovendien hoeft het helemaal geen probleem te zijn. Je kan "." bijvoorbeeld achter in je PATH zetten, dat lost dit meteen ook weer op.

Dan had je dat er wel even bij mogen vertellen, als je toch volledig wil zijn

En als je het achter in je PATH zet, is het nog maar gedeeltelijk opgelost. Als de echte 'ls' om een of andere reden weg zou zijn, of als er een ander commando gebruikt wordt dat niet op het systeem aanwezig is, is ook alles weg.

[Sanjuro]

Op zaterdag 15 september 2001 17:47 schreef RemcoX het volgende:

[..]

Dan had je dat er wel even bij mogen vertellen, als je toch volledig wil zijn

En als je het achter in je PATH zet, is het nog maar gedeeltelijk opgelost. Als de echte 'ls' om een of andere reden weg zou zijn, of als er een ander commando gebruikt wordt dat niet op het systeem aanwezig is, is ook alles weg.

Dat klopt, maar als je mensen op je systeem toe laat die kwaad willen dan lukt ze dat toch wel. Mensen die echt willen zullen een root exploit altijd iets sneller vinden dan jij kan patchen.

[RemcoX]

Op zaterdag 15 september 2001 17:50 schreef Sanjuro het volgende:

[..]

Dat klopt, maar als je mensen op je systeem toe laat die kwaad willen dan lukt ze dat toch wel. Mensen die echt willen zullen een root exploit altijd iets sneller vinden dan jij kan patchen.

Dit is natuurlijk absoluut geen argument. 'Er zullen toch wel meer security weakness'en zijn, dus kan er nog wel een bij...'