HP a écrit
Ouais… écrire des trucs plus jolis… parce là, j'ai même pas envie de lire…
C'est vrai que niveau présentation, il faut prendre les bon plis dès le début. Je te conseille cette lecture sur l'indentation, choisit en une et tiens y toi :
http://fr.wikipedia.org/wiki/Style_d%27indentation (ce n'est pas que pour les autres, tu te rendra vite compte à terme que cette bonne pratique (terme en Anglais "best practice") t'aidera toi aussi à mieux relire ton code, même 1 an après où tu ne te souvient plus forcement de tout.)
Coder, c'est pas que bricoler, c'est aussi communiquer surtout lorsque tu t'adresse à un forum pour avoir des avis.
HP a écrit
Donc, faudrait, a minima, apprendre à écrire des fonctions et, donc, à découper le programme en « unités logiques ».
Pourquoi pas, mais dans le cas présent les fonctions ne sont pas nécessaire. Je dirais que si ton code dépasse une centaine de ligne, tu peut commencer à y penser effectivement.
HP a écrit
Bon, et en plus des fonctions, faudrait aussi découvrir et/ou utiliser les variables, parce que les chemins écrits en dur… c'est moyen.
Clair, il faut que tu rendes tes chemins variants afin de réutilisation et de modification aisée, par exemple en tête de script :
path_home="aaa"
path_partage="$path_home/xxx/ccc"
path_freebox="/zzz/ppp"
Pareil pour les variables, il faut choisir son style et s'y tenir. Ça peut être comme je l'
ai_fait, ou bien
DES_MAJUSCULES ou encore
enCamelCase
HP a écrit
Et une fois de plus, utiliser bash pour çà… c'est (vraiment) n'importe quoi, un simple sh suffit amplement.
Là dessus je ne suis pas d'accord. Bash est le shell par défaut sur toutes les distributions modernes, autant ne pas se passer de sa puissance syntaxique par rapport à sh.
Par contre michol, tu utilise le shebang #!/bin/bash alors que tes tests sont des tests sh. Quitte à utiliser bash, autant aller jusqu'au bout et utiliser des tests de type
[[ ]] au lieu de
[ ]
Si le but c'est la portabilité à tout prix, mieux vaut penser à Ruby, Python ou Perl