Il mio primo script

[namek]

Salve a tutti.
Ho provato a fare un file script per la shella Bash, ma mi dice "command not found".
Guardano in giro sulla rete ho scoperto che la shell cerca nelle directory di PATH e quindi per far funzionare il mio script devo dare il path completo; per essere sicuro che il file sia visto come comando ho provato a fare

<quote>
which EsempioScript
</quote>

dove EsempioScript è il nome del mio script. Non lo trova, non mi dà la directory dove si trova.

Il mio script è questo:

<quote>
#!/bin/bash
for i in $*
do
echo $i
done
</quote>

ho provato a lanciarlo in vari modi, andando sulla directory dove si trova e lanciarlo, oppure dando il percorso assoluto, sempre che io abbia fatto bene a inserire il percorso assoluto, io sono partito così:
<quote>
./home/../../../EsempioScript
</quote>

Ho pure modificato i permessi con chmod per avere la possibilità di lanciarlo.
Che cosa sto sbagliando?
Grazie

[proffi]

Non so se c'entra, hai provato a dargli l'estensione .sh? se come interprete metti /bin/sh cambia qualcosa? dato che gli hai già dato i permessi di esecuzione non mi viene in mente nient'altro, sono un po' indietro con lo scripting bash...
Ciao

[Brolli]

cd nomecartella-contenente-script
chmod u+x nomescript
./nomescript

Dovrebbe andare

Domanda stupida, ma: hai rispettato il case sensitive?

[mimmo.caserta]

Ciao, nn mi vorrei sbagliare ma potrebbe dipendere dal fatto che devi lanciare lo script in questo modo

./NomeScript

il ./ dice alla shell che l'eseguibile che lanci non deve cercarlo solo nella variabile di ambiente PATH ma anche nella directory corrente (se questa non fa parte della variabile PATH).

Spero di essermi spiegato bene.
Ciao

[ramskilo]

il metodo esposto da brolli e Mimmo.Caserta funziona, ma si potrebbe anche modificare il PATH dal file di configurazione ./bashrc o altri. Però penso che questo comporterebbe rischi in più per quento riguarda la sicurezza....

[Brolli]

già, io non metterei mai "./" nella variabile PATH... VVoVe:

[mimmo.caserta]

Beh si...la sicurezza...cmq basta ricordarsi ogni volta di mettere il ./ quando si vuole lanciare un comando che non sia in una delle cartelle specificate in PATH.
Bye

[ramskilo]

a dire il vero non ho mai capito fino in fondo perchè è pericoloso mettere ./ nel PATH... il pericolo implica una disattenzione dell'utente, o ci si espone ad attacchi esterni? qualcuno mi può dare un suggerimento?

[Brolli]

Beh il problema sta nel fatto che se nella cartella in cui sei (./) c'è un programma con un nome identico ad un altro che si trova in un'altra cartella, quando al prompt dai il nome del comando, la shell esegue quello che si trova in ./ e questo apre quindi delle problematiche per quanto concerne la sicurezza!

Un esempio: ipotizza che ./ contenga un programma di nome mv , ora se hai ./ nella path la shell, quando digiti "mv" eseguirà l'mv che si trova in ./; ora ipotizza che l'mv in "./" sia un file contenente codice malevolo (o anche solo un link simbolico a rm)... :rollo:

[U-bahn]

Originariamente inviato da Brolli
[...]quando al prompt dai il nome del comando, la shell esegue quello che si trova in ./

beh, dipende dalla posizione in cui è inserito "." nel PATH: se è l'ultimo, gli eseguibili in ./ vengono considerati solo se non sono stati trovati comandi con lo stesso nome nelle altre directory
...questo perchè bash cerca i comandi nelle cartelle secondo l'ordine specificato in $PATH

ciò non toglie che inserire "." nel PATH possa rappresentare un rischio per la sicurezza...soprattutto se anche root ha "." nel percorso di ricerca dei comandi...quindi, se vuoi metterlo comunque nel PATH ti consiglierei di inserire almeno:

if [ $EUID -ge 1000 ];then

         export PATH=$PATH:.

else 

         export PATH=$PATH (omittibile, insieme ad 'else')

fi

in /etc/profile e/o in ~/.bash_profile, dopo le altre definizioni di PATH