Newsgroup: it.comp.os.linux.iniziare
Titolo: bash: script o libreria?

$ cat server-lib
function info {
     echo qualcosa
}
 
$ cat client
#!/bin/bash
source server-lib
info
 
SECONDO ESEMPIO:
 
$ cat server-script
#!/bin/bash
echo qualcosa
 
$ cat client
#!/bin/bash
./server-script
 
Come vedete nel secondo esempio il *server*, invece di una libreria, è 
costituito da uno script.
 
Quale soluzione preferite?
Dicono che in bash le librerie è meglio evitarle, perchè (condividendo 
lo stesso *unico scope globale*) possono generare conflitti, ecc.

 lo stesso *unico scope globale*) possono generare conflitti, ecc.
 
Oppure possono includere configurazioni nello
script chiamante.
 
Come scrivevo, dipende da cosa serva.
 
bye,
 
-- 
 
piergiorgio

 script chiamante.
 
Prendii ad esempio
 
tput setaf 4 # blue
echo $1
tput sgr0
 
In questo caso è meglio uno script o una libreria (con apposita function)?

 In questo caso è meglio uno script o una libreria (con apposita function)?
 
Forse non ci siamo capiti.
 
Ti riformulo la questione.
 
Cose significa per te "meglio"?
 
Sei tu che devi decidere, *sapendo* i pro e
contro, quale delle due soluzioni sia piu`
adatta al tuo problema.
 
Se tu che sai cosa "meglio" voglia dire.
 
Dato che sai la differenza fra le due possbilita`,
sai i vantaggi e gli svantaggi, dovresti essere in
grado di stabilire cosa "meglio" sia.
 
bye,
 
-- 
 
piergiorgio

 grado di stabilire cosa "meglio" sia.
 
Ogni applicazione dovrebbe essere un processo.
Usando un sub-script vengono creati due processi separati.
E' anche vero però che il sub-script si può caricare all'istante, una 
funzione invece implica il caricamento (+ eventuale configurazione) 
preventivo della libreria.
La libreria naturalmente vive nello stesso processo dell'app e rimane in 
memoria (garantendo tempi di accesso velocissimi alle varie funzioni) 
fino a quando l'app non viene terminata.
Quindi boh :D

 Quindi boh :D
 
Non credo questo sia il ragionamento corretto.
 
Se usi shell script, le prestazioni non sono la prima
cosa a cui pensare.
Certo, non vanno ignorate, ma se quelle (le prestazioni)
fossero il problema, si userebbe C invece di shell script.
 
Ora, la differenza fra i due casi, come tu hai gia` scritto,
e` che con "source" lo script viene eseguito nello stesso
contesto, quindi tutte le funzioni, variabili e quanto altro
sia creato, sono accessibili anche al chiamante.
Nell'altro caso, invece, i due processi sono isolati e, se
dovessero comunicare, dovrebbero farlo in maniera esplicita.
Nota che il contesto del chiamante viene passato al chiamato,
cioe` eventuali variabili esportate dal chiamante diventano
visibili al chiamato.
 
Siccome il principio di isolamento e` sempre valido, la
soluzione "source" si usa, appunto, quando si voglia far
si che funzioni, variabili e quant'altro siano passati
dallo script chiamato al chiamante.
 
Per esempio, uno script puo` contenere delle funzioni di
uso comune e, per poter _installare_ queste funzioni in
un altro script, questo secondo deve chiamare il primo
con "source" e non altrimenti.
 
Quindi, di nuovo, devi valutare tu se hai una necessita`
oppure un'altra.
 
bye,
 
-- 
 
piergiorgio

 
 
In realtà dei punti fermi ci sono.
 
Quando uno script diventa un minimo complesso bisogna creare delle funzioni.
Le funzioni devono essere poste prima del loro utilizzo, il che può far  
diventare fastidioso arrivare a poter leggere l'inizio del programma.
 
La soluzione è mettere le funzioni in altri file e inserirli nel file 
principale con source.
(volendo c'è' la possibilità di fare un file unico, che carica se stesso 
(per caricare prima le funzioni), ma è un workaround).
 
Se poi lo script si vuole pacchettizzare, quindi inserire un sistema di 
installazione, di traduzione dei messaggi, ecc., avere tanti file è 
obbligatorio, a quel punto file più file meno ...
 

 obbligatorio, a quel punto file più file meno ...
 
????

 .sh, .lib?
]zac[
 
Non importa, di solito niente o sh .