Krijg scripts niet executable

Ik heb twee scripts in de /usr/local/bin directory geplaatst. chmod +x <file> gebruikt om ze executable te maken. maar als ik vervolgens de naam van het script intik, krijg ik de melding "Command not found.". Ook als ik in de directory zelf zit (dan zou het path toch niet uit moeten maken? of is dit mijn DOS jeugdtrauma dat opspeelt?)

Groet, Richard

Hallo Richard,

Als ik het goed begrijp geeft het chmod commando geen foutmelding, maar als je daarna het script uitvoert wel.

Ik denk dat je executable permissies wel kloppen. Probeer anders eens ls -l <file>, om te controleren of er echt x-jes aangegeven staan: bijv. -rwxr-xr-x (…) <file>

Als dat zo is dan is wordt de foutmelding dus veroorzaakt door iets in je scriptje, hoogstwaarschijnlijk is de interpreter van het scriptje niet te vinden in je path. Waarschijnlijk begint je script met een hekje, uitroepteken en dan de naam van de interpreter van het script: bijv. #!/usr/bin/sh ofzoiets… Als /usr/bin/sh niet zou bestaan in dit voorbeeld of er zit een typefout in, dan veroorzaakt dat jou foutmelding.

[quote:2f071c69e6="richardk"]Ik heb twee scripts in de /usr/local/bin directory geplaatst. chmod +x <file> gebruikt om ze executable te maken. maar als ik vervolgens de naam van het script intik, krijg ik de melding "Command not found.". Ook als ik in de directory zelf zit (dan zou het path toch niet uit moeten maken? of is dit mijn DOS jeugdtrauma dat opspeelt?)

Groet, Richard[/quote:2f071c69e6]

Standaard staat /usr/local/bin niet in je PATH. Zoals je wellicht gezien hebt, is op een nieuw systeem /usr/local helemaal leeg: Apple zet daar niks in zodat jij daar lekker je eigen spullen in kan prakken. Ik heb in mijn home directory een .bashrc file staan, met de volgende regel:

[code:1:2f071c69e6]PATH=${PATH}:/usr/local/bin:/usr/local/sbin[/code:1:2f071c69e6]

Je zou (als subtiliteit) ook kunnen kiezen de /usr/local directories eerst te noemen en dan pas het bestaande PATH, maar dat laat ik aan jou over.

De directory waarin je je bevindt zit standaard ook niet in het pad. Dus als uitbreiding op de eerder genoemde toevoeging aan .bashrc het volgende:

PATH=.:${PATH}:/usr/local/bin:/usr/local/sbin

De . als eerste positie zorgt ervoor dat er altijd eerst in de huidige directory wordt gezocht. Zonder dit lukt het trouwens ook: als bijvoorbeeld je script scr heet, roep je het aan met ./scr ipv scr.

[quote:00b49e1c14="nuance"]PATH=.:${PATH}:/usr/local/bin:/usr/local/sbin

De . als eerste positie zorgt ervoor dat er altijd eerst in de huidige directory wordt gezocht. Zonder dit lukt het trouwens ook: als bijvoorbeeld je script scr heet, roep je het aan met ./scr ipv scr.[/quote:00b49e1c14]
De . in het begin van je pad geeft kwaadwillenden wel de mogelijkheid om je verkeerde dingen te laten uitvoeren, omdat ie bij het doorzoeken van het pad alle bestanden in de current directory voorrang geeft. Beter kan je . niet in het pad zetten, maar wel alle betrouwbare directories, OF als je per-se de local-dir in je pad wil houden, die . aan het einde zetten.

Groeten, Hurly.

[quote:4c4f88a945="richardk"]Ik heb twee scripts in de /usr/local/bin directory geplaatst. chmod +x <file> gebruikt om ze executable te maken. maar als ik vervolgens de naam van het script intik, krijg ik de melding "Command not found.". Ook als ik in de directory zelf zit (dan zou het path toch niet uit moeten maken? of is dit mijn DOS jeugdtrauma dat opspeelt?)

Groet, Richard[/quote:4c4f88a945]
Hoi Richard,

Als je die 2 scripts aanroept vanuit unix, moet (buiten dat ze executable zijn, zoals je doet met chmod) je scripts ook beginnen met op de eerste regel:

[code:1:4c4f88a945]#!/bin/sh[/code:1:4c4f88a945] (of een andere shell/interpreter voor je script. Klopt het pad naar die interpreter/shell niet, dan krijg je ook zo’n foutmelding.

Groeten,

Hurly.

In de directory zelf moet je toch aangeven dat het in die directory staat. Unix zoekt niet standaard in de huidige directory zoals dos. Dus ./scriptnaam typen (met punt aan het begin dus) of met de volledige padnaam, dus /usr/local/bin/scriptnaam in jouw geval.

Hans

Hallo allemaal,

Ik heb en probleempje in het verlengde van het bovenstaande.
Ik heb een (getest) scriptje in mijn /usr/local/bin gezet.
Nou probeer ik het pad /usr/local/bin aan mijn $PATH toe te voegen dmv een .bashrc file (die ik nu voor het eerst maak) in mijn homedir en dat werkt niet.
Het viel me op dat daar ook al een .tcshrc file staat. Is dat standaard? Lijkt me niet toch? Vooral omdat bash standaard is en niet tcsh? (draai osx 10.3.8 )
Ik vermoed dat de file daar is gekomen tijdens installeren van mysql. (althans, de enige regel die in de file voorkomt heeft daarmee te maken)
De vraag: zorgt het voor conflicten als ik naast een .bashrc ook een .tcshrc file in mijn homedir staat en kan dat de bron zijn van het onbereikbare pad /usr/local/bin?
Of definieer ik $PATH verkeerd?
De inhoud van de .bashrc file:

[code:1:c8c2124b5d]PATH=${PATH}:/usr/local/bin:/usr/local/sbin[/code:1:c8c2124b5d]

groeten

.tcshrc wordt gebruikt door de shell interpreter van os x10.2. in OS X 10.3 is dit gewijzigd naat bash en heb je .bashrc of .profile nodig.

Als je echter geupgrade hebt van 10.2 naar 10.3 dan wijzigt de shell niet. Blijft dus de T-shell (of hoe heet dat ding ook al weer :?

Dit kun je wel achteraf wijzigen.

Hans