Newsgroup: it.comp.os.linux.iniziare
Titolo: script

Salve ...
ï¿œ possibile rendere eseguibile uno script tipo bash e
succesivamente poterlo lanciare senza il ./
Grazie.


Certo, basta dire a "bash" dove si trova lo script.
 
Il "path" "./" significa "qui".
 
Ma bash cerca in $PATH gli eseguibili, per cui le
soluzioni sono: mettere lo script in un posto definito
in $PATH, ovvero mettere in $PATH il posto dove si
trova lo script.
 
Per dettagli "man bash" e cercare "PATH" tra le variabili
di sistema.
 
bye,
 
-- 
 
piergiorgio

 succesivamente poterlo lanciare senza il ./
 
Si'. ma il prezzo da pagare e' che devi aggiungere, alla variabile PATH,
la directory . ("punto", cioe' dove ti trovi) e questo puo' essere molto
pericoloso.
Se vuoi farlo lo stesso devi aggiungere questa riga:
PATH="$PATH:."
alla fine del file .profile che hai nella tua home.
 
-- 
Tanti saluti
 

 alla fine del file .profile che hai nella tua home.
 
Ti aggiungo che ti conviene, molto di piu' e per piu' motivi, creare la
directory bin nella tua home, aggiungerla nel path (ci metti lei invece
del punto che t'ho detto prima) e infine spostare li' ogni eseguibile
(script) che ti fai e ti farai.
 
Vedi, nella Debian questo e' previsto, guarda alla fine del .profile di
/etc/skel/ cosa c'e':
----------------------------
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi
--------------
Quindi se hai la Debian non hai bisogno d'aggiungere nulla, ti basta
creare la directory bin e metterci dentro gli eseguibili tuoi.
 
Curiosita': La Debian lo mette in prima posizione di ricerca, io l'ho
messo in ultima, inoltre la bin l'ho messa in /home, non nella mia home,
perche' dev'essere disponibile a tutti gli utenti (anche se sono sempre
io, ma con diversi nomi e mansioni per ogni diverso nick).
 
-- 
Tanti saluti
 

 e questo puo' essere molto pericoloso.
 
Meno male che lo sai
 
 

 Grazie.
 
è necessario e sufficiente che sia nel path. molte distribuzioni 
includono la directory ~/bin e/o ~/.local/bin nel path dell'utente, 
quindi basta che lo copi in quelle directory.

 succesivamente poterlo lanciare senza il ./
 
Leggere una guida o un manuale *PRIMA* è troppo difficile?

 io, ma con diversi nomi e mansioni per ogni diverso nick).
 
Queste sono due questioni di gusti e preferenze personali.
Per quanto riguarda la locazione degli eseguibili personali di solito la
scelta è ~/bin ma nella tua $HOME fai  quello che vuoi tu. Discorso 
diverso per gli script accessibili a più utenti; dovrebbero andare in 
/usr/local/bin e root deve essere il proprietario.
  Invece in $PATH ~/bin deve essere l'ultima directory per motivi di 
sicurezza. Ovviamente questo si scontra con altre considerazioni 
sulla praticità di tale scelta per cui conviene che ~/usr sia la prima 
directory in cui cercare; se tu installi una versione personale di un 
programma di sistema (cosa da sconsiglire ma a volte necessaria)
vorrai che sia questa ad essere eseguita e quindi questa deve essere
trovata per prima e qiundi ~/bin deve essere la prima directory.
  Questa è la teoria, io ho messo /home/mallin/bin come ultima 
directory in $PATH, a voi decidere cosa è meglio fare.
 
 


Esiste anche un vantaggio (non grande) avere per primi i path di sistema
La shell esegui i tentativi di ricerca seguendo le directory impostate 
in PATH
Quindi con i path di sistema all' inizio gli eseguibili di sistema 
vengono trovati prima
 
 
 
 

 sistema vengono trovati prima
 
le directory di sistema sono di default in testa al path non certo per 
questo, serve ad evitare che "omonimie" più o meno accidentali con 
comandi di sistema possano fare danni. ciò non toglie che, per lo stesso 
motivo di priorità di path, si possa coscientemente invertire. 
dal punto di vista performance le directory hanno un indice e ricercare 
puntualmente un file contenuto ha un costo trascurabile anche in presenza 
di migliaia di file.


Infatti avevo affermato che i vantaggi non sono grandi
Per completezza la shell non cerca l'eseguibile leggendo la directory, 
fa semplicemente una exec (dopo la fork ovviamente)
Se la exec fallisce prosegue con la prossima directory nel path per 
comporre il nome dell' eseguibile e ritentare con un altra exec e cosi 
avanti
 
 

 motivo di priorità di path, si possa coscientemente invertire.
 
Normalmente io (ma perché so quello che faccio) preferisco avere 
$HOME/bin come primo percorso in PATH, perché in questo modo posso 
crearmi dei comandi che siano un "override" di quelli di sistema. Col 
ragionamento, condivisibile o meno ma con la sua logica, che se mi creo 
un comando omonimo (ma diverso) di uno di sistema, è perché quello di 
sistema non mi soddisfa.
 
Anche se per esigenze simili, a dire il vero, esiste l'alternativa di 
"alias", che ottiene più o meno lo stesso scopo.
 
Ovviamente a un utente che manco sa quello che fa non suggerirei mai una 
cosa simile, rischierebbe di fare danni incalcolabili senza neanche 
rendersene conto.
 
Insomma... dipende come sempre cosa si vuole fare. L'importante è sapere 
quello che si sta facendo :-)
 
-- 
Massimo Bacilieri AKA Crononauta

Addi' 11 dic 2013, enoquick scrive:

Pero' scusate ma a me sembra che la Debian l'abbia fatto apposta di
mettere ~/bin in testa. E' una questione del tutto simile agli alias,
che hanno precedenza assoluta.
Ad esempio io ho fatto /home/bin/ffmioprobe cosi':
--------
#!/bin/bash
 
ffprobe "$1" 2>&1 | grep -vE "ffprobe|configuration:|^\ \ lib"
-----------------
 
che non si puo' mettere come alias. Ebbene, col ~/bin in testa potrei
chiamarlo tranquillamente ffprobe, riservandomi di chiamare l'autentico
con /usr/bin/ffprobe.
 
-- 
Tanti saluti
 

 quello che si sta facendo :-)
 
Ho appena scritto lo stesso (ho letto dopo il tuo reply), pero' io un
po' d'esperienza ce l'avrei pure, solo che in primo luogo non mi
dispiace cambiar nome, inoltre non ci vedo chiaro fino a che punto gli
altri programmi chiamano l'originale sempre col path completo.
 
Pero' c'e' anche un ultimo motivo, ed e' che con nomi di fantasia potrei
andare ad incocciare proprio nomi di programmi che potrei installare in
futuro (molte utility hanno nomi diversi da quelli del pacchetto, quindi
installadoli potrei non accorgermene).
 
-- 
Tanti saluti
 


Infatti i vantaggi non sono cosi grandi, in pratica è una questione di 
gusti ed opportunità
Anch' io uso la tecnica da te descritta, quella di mettere le proprie 
directory di bin in testa per giochetti come quello che hai descritto
 
 
 

 [...]
 
Attento, si sta per scatenare una guerra di religione, una 
guerra iniziata più di quarant'anni fa insieme ad UNIX, una
guerra più vecchia di molti abbonati a questo gruppo.
 
 


Grazie a TUTTI ...
 

 Grazie a TUTTI ...
 
Per esempio, per aggiungertene una circa la sicurezza di non mettere la
directory di lavore, cioe' la ., nel path: la grande Slackware - se non
ricordo male - la include di sistema nel path degli user, di root no.
Quindi vedi tu, io l'avevo tolta subito, finita l'installazione.
Chissa' l'Ubuntu cosa fa...
 
-- 
Tanti saluti