shebang e concetti di base, Re: [Arduino] R: R: Re: [Soci SLIP] Corso Arduino Python Qt

[loredana]

Sposto questo thread nel posto in cui ragionevolmente dovrebbe stare e
cambio l'oggetto. Al fondo trovate i due interventi precedenti. Non
voglio rubare il thread, solo continuo a sottolineare che almeno
imparare ad usare una mailist lo si dovrebbe fare, persino in SLiP. Se
il presidente e i consiglieri ci provano, magari gli altri seguono. E'
il primo passo, come sottolineava Lucio, per partecipare ad una
comunita'. E permettere di partecipare vuol anche dire non fare
impazzire con il diordine piu' totale, divieti di leggere questo o
quello etc.

ora si passa a shebang e concetti di base:

L'uso di #!/usr/bin/env non ha nulla a che vedere specificatamente con
python.

/usr/bin/env e' un comando di sistema che aggiunge un livello di
ridirezione, favorendo la portabilita' dello script in ambienti diversi.

Lo script puo' essere in bash, in perl, in octave in qualsiasi altra
cosa. Per esempio:

#!/usr/bin/env perl
#!/usr/bin/perl

sono equivalenti sui sistemi in cui l'interprete perl (o python, o sh, o
octave etc) si trova in /usr/bin, ma il primo funziona e il secondo no
quando l'interprete perl non e' in /usr/bin (per esempio, e'
in /usr/local/bin). 

Se si porta lo script da un sistema in cui l'interprete perl e'
in /usr/bin ad uno in cui e' in /usr/local/bin e si usa la seconda
forma, occorre modificare lo script, specificando nella prima riga il
percorso corretto. Se si usa la prima forma, no, perche' il
comando /usr/bin/env si occupa di cercare lui dove sta l'interprete
perl, usando la variabile $PATH dell'environment (ambiente).

Inoltre, come diceva Alessandro P., siccome /usr/bin/env cerca nella
variabile $PATH, aggiungendo in testa a questa variabile un percorso
diverso per l'interprete, si puo' usare lo stesso script che inizia con
la prima forma per usare un interprete (perl o altro) diverso, visto che
il comando env usa il primo che trova in $PATH. Questo puo' essere utile
per testare il funzionamento dello script con una versione
dell'interprete diversa da quella installata di default sul nostro
sistema, per esempio.

Ovviamente, il problema si sposta solo di un gradino, perche' ora
e' /usr/bin/env che deve essere in /usr/bin, altrimenti non lo trova
etc. Ma la gerarchia del file system nei sistemi UNIX-like e dove
mettere i programmi di base e non e' stata raffinata nei decenni e
standardizzata ed e' per questo che se le varie distribuzioni la
rispettano si e' certi che il funzionamento sottostante, al di la' della
superficie, e' lo stesso. Questo permette la portabilita' ed un enorme
risparmio di energie nel non far lavoro inutile. Inoltre, chi lo sa ne
puo' approffittare anche lui/lei, anche se non e' uno sviluppatore
professionista, perche' lo standard ha a che fare con l'uso del sistema
di tutti i giorni, anche se nessuno sembra be' saperlo, ne', sapendolo,
dirlo piu'.

Per una buona spiegazione dell'uso e significato, in particolare,
di #! potete leggere qui (la corrispondente versione italiana e'
tagliata qui e la' malamente, come al solito):

http://en.wikipedia.org/wiki/Hash-bang

Qualsiasi sia l'interprete che usate, poi, per i vostri script, e sia
che usiate la prima o la seconda forma, ricordatevi due cose, se volete
eseguire lo script usando il solo nome del file:

1) quel file deve essere eseguibile (in GNU/linux basta dare il comando
chmod +x nome_del_mio_file

2) la directory da cui lo eseguite deve essere nel vostro $PATH. Se in
path compare piu' volte lo stesso script ma in diretcory diverse, verra'
usato quello che compare per primo

Ne segue che se il vostro script e' nella directory corrente (in genere,
la vostra home) e il carattere ".", che si riferisce alla directory
corrente non e' in $PATH, anche se lo script e' esguibile, vi verra'
dato un messaggio di errore (command not found o quello che e' in
italiano). Potete sempre rimediare dando, al prompt, il comando:

./nome_del_mio_file

cioe' specificando la directory corrente (./) o qualsiasi altro
percorso.

Tutto infatti si basa sul concetto piu' generale di individuazione della
posizione del file, che e' data dal percorso (directory e subdirectory)
per arrivarci piu' il nome stesso del file. Il percorso poi puo' essere
assoluto o relativo. 

Android non rispetta nulla di tutto cio', ma gli stessi concetti di file
system gerarchico (percorso piu' nome file) si applicano a tutti i
sistemi che ho visto finora (windows incluso e html incluso, dove l'url
non e' altro che un percorso piu' nome file preceduto dalla macchina,
che in locale non occorre specificare, ma ovviamente quando si va in
rete si').

Il punto e' che bisogno trovare quello che si vuol usare e questo vale
per un file in rete o in locale o in uno script, per un'applicazione in
rete o in locale o in uno script etc etc. 


Loredana

On Mon, 2013-12-02 at 10:29 +0100, Alessandro Pasotti wrote:
Il giorno 02 dicembre 2013 09:41, Lucio Crusca <lucio a sulweb.org> ha
scritto:
> In data lunedì 2 dicembre 2013 08:44:13, Alessandro Pasotti ha
scritto:
>         > #!/usr/bin/env python
>         >
>         > [...]
>         >
>         > PS: il metodo descritto sopra non ha nulla di specifico per
python, vale
>         > per qualsiasi interprete: bash, php, ruby, perl e chi più ne
ha ....
>         
>         
>         Sì, però per qualche motivo che non ho mai capito, nel caso di
python bisogna
>         
> 
> non bisogna, si può
> 
> 
>  
> passare per il comando env, mentre gli altri possono essere richiamati
>         direttamente, tipo così:
>         
>         #!/bin/bash
>         
>         o
>         
>         #!/usr/bin/perl
>         
> 
> 
> 
> nessuno ti vieta di usare #!/usr/bin/python o quale che sia il tuo
path.
> 
> 
>  
> 
>         Tenuto conto che, per quel che ho capito del comando env, se
non gli passi
>         parametri che modificano le variabili d'ambiente, praticamente
non fa nulla,
>         non riesco a capire la necessità di usare env nel caso di
python.
>         
> 
> il fatto è che il tipico sviluppatore python usa un aggeggio che si
chiama virtualenv, il quale permette di avere degli ambienti di sviluppo
isolati, nei quali volendo possono essere utilizzati anche interpreti
python differenti, usando env, non è necessario scrivere il path
completo che porta all'interprete dato che ci pensa env a trovarlo.
> 
> 
> Permette di scrivere un programma più portatile, dato che non è legato
ad un path particolare per l'interprete.
> 
> 
> 
> 
> -- 
> Alessandro Pasotti
> w3:   www.itopen.it