Newsgroup: it.comp.os.linux.iniziare
Titolo: parametri per sotto comando

$ cat test.sh
#!/bin/bash
function sub_command {
     # parsing locale
     local options
     options=$(getopt -o s --long "sub-test" -- "$@") \
         || exit 1
     eval set -- "$options"
     while true; do
         case "$1" in
             -s|--sub-test)
                 SUB_TEST=0
                 shift
                 ;;
             --)
                 shift
                 break
                 ;;
         esac
     done
 
     # FAI QUALCOSA...
}
 
# parsing globale
options=$(getopt -o t --long "test" -- "$@") \
     || exit 1
eval set -- "$options"
while true; do
     case "$1" in
         -t|--test)
             TEST=0
             shift
             ;;
         --)
             shift
             break
             ;;
     esac
done
 
# esecuzione sotto-comando
$1 "$@"
 
Come vedete abbiamo un parsing globale per parsare le opzioni relative 
all'intero script, e un parsing locale per parsare le opzioni relative 
solo alla function sub_command.
 
Proviamo quindi se tutto funziona
 
$ ./test.sh --test sub_command --sub-test
getopt: opzione non riconosciuta "--sub-test"
 
Qualcosa non va, e intuisco che il problema è che il parsing globale, 
tenta di parsare anche l'opzione --sub-test, che giustamente non riconosce.
Tale opzione infatti se la dovrebbe parsare la function sub_command per 
conto suo.
 
Come fare?

 Come fare?
 
Evitare certe porcherie.
 
Il parsing si fa in un unico posto, si creano poi
i parametri per le varie funzioni, come risultato
di suddetto parsing.
 
bye,
 
-- 
 
piergiorgio


io farei una cosa di questo genere:
 
./test.sh <sub_comand> <args>
 
cosi la getopt non la fai nel main ma per ogni sub_command
 
 

 cosi la getopt non la fai nel main ma per ogni sub_command
 
 
Ascolta, prendiamo come esempio composer:
 
$ composer -h
Usage:
   help [options] [--] [<command_name>]
...
 
$ composer update -h
Usage:
   update [options] [--] [<packages>]...
...
 
Come vedi i due comandi danno risultati diversi, e si dovrebbe intuire 
(IHMO) che viene usato proprio il concetto di cui avevo parlato (*global 
scope* e *local scope*).
Possibile che non si può ottenere un risultato simile?


$file $(which composer)
/usr/bin/composer: a /usr/bin/php script, ASCII text executable
 
non e' uno script di shell
 
 
Comunque,come scritto da me nel post precedente:
 
 
cmd=shift
case "$cmd" in
	cmd1)
		#fa la getopt di cmd1 e la esegue
		;;
	cmd2)
		#fa la getopt di cmd2 e la esegue
		 ;;
	-h)
		usage()
		exit 0
		;;
	-*)
		echo "$cmd - opzione errata" >&2
		exit 1
		;;
 
	*)
		echo "$cmd - comando errato" >&2
		exit 1
esac
 

 di suddetto parsing.
 
Leggi gli altri post e, quindi, proponi la tua soluzione.

 esac
 
In pratica *getopt* bisogna usarlo solo per i comandi.

 Leggi gli altri post e, quindi, proponi la tua soluzione.
 
La soluzione e` evitare di fare il parsing locale,
anche perche`, in shell, locale e globale sono cose
non troppo ben definite.
 
Nel tuo esempio di "composer", come e` scritto tale SW?
 
Hai guardato i sorgenti?
C'e` la soluzione che cerchi, direi.
 
Ad ogni modo, si puo` sempre fare una funzione che fa il
parsing e che riceve, come parametro, quale tipo di
parsing fare, se e` del programma o di un sotto-modulo.
 
bye,
 
-- 
 
piergiorgio

 parsing fare, se e` del programma o di un sotto-modulo.
 
In pratica tu proponi questa struttura:
 
main-parsing
	command1-parsing
	command2-parsing
	...
command1
	fai-qualcosa
command2
	fai-qualcosa
 
Invece l'amico enoquick propone:
 
main-parsing
command1
	parsing
	fai-qualcosa
command2
	parsing
	fai-qualcosa
...
 
Non so cosa scegliere :D


Ma e` lo stesso, poiche` e` fatto nella stessa funzione.
 
Sarebbe diverso, se fosse fatto in posti diversi.
 
Il che, ripeto, potrebbe avere senso, ma immagina solo i
problemi che possono nascere durante testing / debugging.
 
Una delle cose che bisogna *sempre* tenere presente e`:
come si fa a sapere dove e` il problema, in caso di problemi?
 
Se si sparpaglia il codice in "n" funzioni, diventa complicato
fare il debugging in caso di problemi.
 
Quindi la risposta la hai gia`: se non vi sono altre ragioni,
metti assieme tutto quello che deve stare assieme.
 
bye,
 
-- 
 
piergiorgio

 In pratica *getopt* bisogna usarlo solo per i comandi.
 
Esatto
non si puo fare una getopt globale se ogni cmd ha le sue opzioni
 

 metti assieme tutto quello che deve stare assieme.
 
Il fatto è che abbiamo due concetti diversi :D
Io tendo a raggruppare per moduli.
Tu tendi a raggruppare per funzionalità.

 
 
$ cmd=shift; echo $cmd
shift
 
????

 Tu tendi a raggruppare per funzionalità.
 
E tu hai moduli diversi con funzionalita` uguali?
 
Mi pare chiaro che ogni modulo avra` la sua funzionalita`,
altrimenti hai duplicazione di codice.
 
Non sono due concetti diversi, sono lo stesso.
 
Si deve solo chiarire cosa sia "funzionalita`".
 
Nel tuo concetto, avrai semplicemente un "modulo"
per fare il parsing, non mi sembra cosi` diverso.
 
Ripeto, a meno che non vi siano ragioni speciali
per fare altrimenti.
 
bye,
 
-- 
 
piergiorgio

 per fare altrimenti.
 
OK, ad ogni modo valuterò anche il tuo punto di vista :D

 OK, ad ogni modo valuterò anche il tuo punto di vista :D
 
In generale, se hai moduli, questi dovranno essere,
per definizione, isolati gli uni dagli altri (senno`
non sono moduli).
 
In questo caso, ovviamente, il parsing puo` essere
fatto in ogni modulo indipendentemente.
 
Questo perche` non c'e` niente di globale, ma e`
tutto locale, ed eventuali parametri sono passati
*esplicitamente* da una parte del SW all'altra.
 
E` lo stesso concetto di un shell script.
 
Nello script, ogni comando e` indipendente (come
codice) dagli altri ed ha un suo parsing degli
argomenti interno, sempre indipendente dal resto.
 
In uno stesso shell script, pero`, dato che la
distinzione tra locale e globale diventa vaga, non
conviene avere un parsing per funzione, perche`
c'e` il rischio di perdere il controllo di cosa
succeda, quindi conviene usare un parsing centrale.
 
In pratica, di nuovo, bisogna aver ben chiara quale
sia l'architettura piu` adatta al problema che si
vuole affrontare, e poi decidere di conseguenza quali
siano le soluzioni migliori.
 
bye,
 
-- 
 
piergiorgio


cat > pippo.sh <<!
#!/bin/sh
 
echo $@
 
cmd=$1
shift
 
echo $cmd
echo $@
!
 
$chmod +x pippo.sh
 
$./pippo.sh aaa bbb ccc
aaa bbb ccc
aaa
bbb ccc
 
piccola confusione - shift non ritorna un valore
 
piccola confusione
shift non ritorna
 
 
 

 siano le soluzioni migliori.
 
Valuterò, grazie :D

 piccola confusione - shift non ritorna un valore
 
Adesso ci capiamo, cmq in bash le funzioni possono restituire solo 
valori numerici.
 


e' un exit code,come quello di un normale comando:
 
$cat > pippo.sh <<!
#!/bin/bash
 
function f {
	echo "ddd"
	return 5;
}
 
 
x=$(f);
echo $?
echo $x
!
$ chmod +x ṕippo.sh
$ ./pippo.sh
5
ddd
 
 
 
 

 e' un exit code,come quello di un normale comando:
 
si si