Discussion :

[JeitEmgie]

Problème:

Solutions:
Une première possibilité est d'utiliser la commande seq:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for i in $(seq 10)
do
    echo "i: $i"
done

Et la seconde possibilité est d'utiliser la syntaxe arithmétique de Bash:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for ((i = 1; i <= 10; i++))
do
    echo "i: $i"
done

Bon, la première solution est certainement plus portable vers les autres shells...

il y a aussi jot qui est aussi utile pour générer des séquences…

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
jot: jot - print sequential or random data
usage:  jot [ options ] [ reps [ begin [ end [ s ] ] ] ]
Options:
	-r		random data
	-c		character data
	-n		no final newline
	-b word		repeated word
	-w word		context word
	-s string	data separator
	-p precision	number of characters

[jmelyn]

Merci JeitEmgie pour la commande jot, qui n'est cependant pas répandue: il faut en général télécharger les sources et compiler soi-même.

J'ai encore une autre manière de faire, en utilisant directement le shell, encore une fois:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for i in {1..10}
do
    echo "i: $i"
done

Et ça marche même avec les lettres:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for i in {A..Z}
do
    echo "i: $i"
done

[jmelyn]

Problème:
Je voudrais être sûr que le fichier de configuration toto.conf du programme toto ait bien la ligne "ligne hyper importante = moi personnellement je", que la ligne n'apparaisse qu'une seule fois et que ce soit exactement celle-là si elle y est déjà.

Solution:
Je tombe régulièrement sur ce genre de problème et suite à un fil, je place la solution que j'utilise maintenant régulièrement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
line="ligne hyper importante = moi personnellement je"
selection="^ligne hyper importante = "
confFile="toto.conf"
awk -v l="$line" -v s="$selection" '
{
  if ($0 !~ /^#/ && $0 ~ s) {if (!done) {print l; done=1}}
  else {print}
}
END {if (!done) {print l}}' $confFile > $confFile.new
mv -f $confFile.new $confFile.new

Explications:

• Les trois premières lignes initialisent des variables. Pas important.
• La première partie de awk permet de ne pas tenir compte des commentaires et de forcer la ligne si elle est trouvée. Dans ce dernier cas, les éventuelles lignes suivantes identiques sont supprimées.
• La dernière partie de awk ajoute la ligne si elle n'a pas été détectée.

[n3wborn]

Problème:
Les alias sont très intéressants pour accélérer le "tapage" des commandes. Style ll pour ls -l. Il suffit de taper alias pour voir ce qui est disponible. Pour le root, j'obtiens (Fedora 8):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
alias cp='cp -i'
alias l.='ls -d .* --color=auto'
alias ll='ls -l --color=auto'
alias ls='ls --color=auto'
alias mv='mv -i'
alias rm='rm -i'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'

Cependant, dans un script, je peux vouloir supprimer un fichier sans avoir à confirmer manuellement que "oui, je veux effectivement supprimer ce p!@#$n de fichier!" Comment ne pas utiliser l'alias rm='rm -i' dans mon script?

Deux solutions:
* En mettant le chemin absolu de la commande /bin/rm mon_fichier.
* En échappant la commande \rm mon_fichier.

Il y a un aussi moyen tout simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

unalias rm

qui permet de désactivé l' alias dans le shell courant.
Désolé, en ecrivant ce message je n' avais pas vu le message indiquant que les scripts ne prenaient pas en compte les alias.Je laisse quand même ceci pour info au cas où...
Pour le supprimer définitivement; il suffit d' éditer ~/.bash_rc avec votre éditeur de texte favori (vi ) et de supprimer la ligne concernant l' alias ou de la commenter.

La plupart de mes scripts prennent un ou des fichiers en entrée, travaillent les données de multiples façons et donnent un ou plusieurs fichiers en sortie. Les traitements peuvent être long et complexes et nécessitent souvent plusieurs traitements à la suite. J'utilise donc des fichiers temporaires. Le problème est le nommage de ces fichiers, ainsi que leur nettoyage. Où les mettre? Dans le répertoire du (des) fichiers d'entrée, de sortie?

On oublie souvent que les tubes (Fifo) nommés existent aussi!!
Utilise t on des fichiers temporaires quand on peux utiliser des tubes?Très utile les tubes fifo...

[jmelyn]

Merci n3wborn pour ta contribution. Je dirais que j'utilise beaucoup les fichiers intermédiaires pour des raisons de debug (déverminage, je crois). Lorsque je dois faire des traitements sur les dizaines de milliers de lignes avec des awk complexes, des join velus ou des sed bien compacts, j'aime voir toutes les étapes, vérifier que le nombre de lignes est correct, et éventuellement déterminer où se trouve l'erreur.

Finalement, l'utilisation des fichiers intermédiaires n'est pas si pénalisante que cela si le code est bien pensé, notamment en évitant autant que faire se peut les boucles.

[ripat]

Exemple 1: L'effondrement du mur de Berlin, c'était quel jour?
D'abord, petit tour sur Wikipépia me donne le 09 novembre 1989.
Puis, le man de date -d m'indique comment passer la date en nombre de secondes.
Ensuite le man de awk au châpitre Time functions me propose strftime() qui me va bien.
Enfin, le man de strftime, fonction C, me fournit le bon argument: %A.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
date -d 1989-11-09 +%s | awk '{print strftime("%A", $0)}'
Thursday

Pourquoi pas simplement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ date -d 1989-11-09 +%A
jeudi

Ou, en anglais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ LANG=C date -d 1989-11-09 +%A
Thursday

[ripat]

Si on veut qu'un script ne tourne pas s'il est déjà lancé par un autre utilisateur. Ou bien si on souhaite qu'un script ne se lance pas si un autre est toujours occupé, classiquement, on peut créer un "lock file" qui est détruit quand le script se termine et tester son existence. Il y a plus simple: la commande lockfile.

Un petit exemple que vous pourrez développer:

Exemple, premier processus:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lockfile /tmp/lock; sleep 10; rm -f /tmp/lock

Le second processus attendra tant que le premier est occupé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lockfile /tmp/lock && echo "Enfin! C'est pas trop tôt..."; rm -f /tmp/lock

Le second processus s'interrompt si le premier est occupé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lockfile -r0 /tmp/lock && echo "Enfin! C'est pas trop tôt..."; rm -f /tmp/lock

Voir aussi les autres options telles que sleeptime.

Source:
http://www.unix.com/shell-programmin...#post302364124

[jabbounet]

Vérifier que l'environnement est correctement configuré.


Parfois certains script ont besoins d'utiliser des variables d'environnements pour effectuer certaines actions.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
echo ${MAVAR:?} > /dev/null

En début de script, placer ce genre de ligne évite d'avoir un script qui s'execute à moitié avant de planter et laisser le systeme dans un etat bancal.

[jmelyn]

Merci Ripat pour l'info. J'avais quelque chose que je mets ici, des fois que cela intéresse quelqu'un...
Certains scripts d'admin ne doivent pas être exécutés plusieurs fois en parallèle. Il est peu probable que deux admins fassent tourner ces scripts en même temps, mais si cela arrivait, ce serait vraiment gênant. Alors voici ce que j'ai écrit.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#!/bin/bash
 
# init
execName=$(basename $0)
lockFile="/tmp/$execName.pid"
 
# check lock
if [[ -f $lockFile ]]
then
  isRunning=$(ps -ef | awk -v p=$(cat $lockFile) -v e=$execName '$2 == p && $NF ~ e {print "true"}')
  if [[ $isRunning == "true" ]]
  then
    owner=$(ls -l $lockFile | awk '{print $3}')
    ago=$(ls -l --time-style=+%s $lockFile | awk -v f=$lockFile '$NF == f {print systime() - $6}')
    echo "ERROR: $execName already started $ago sec ago by $owner. Nothing done, exiting..."
    exit 1
  else
    rm $lockFile
  fi
fi
 
# set lock
echo $$ > $lockFile
chmod 666 $lockFile
 
# script ...
 
# end
rm $lockFile

Les points intéressants sont:

• On sait si le script est en train de tourner.
• On sait qui l'a lancé.
• On sait il y a combien de temps.
• Si le script est mal sorti et n'a pas nettoyé son fichier, c'est fait automatiquement.

Si vous avez des idées sur ce bout de code (intérêt, optimisation), je suis toute ouïe.

[ripat]

C'est dans l'idée de lockfile qui, lui aussi, peut nettoyer le sémaphore après un certain délai (option locktimeout). Ton script le fait si plus aucun processus n'utilise le sémaphore. C'est pas plus mal.

Voici ta version, optimisée et débarrassée des bashismes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# init
lockFile="/tmp/${0##*/}.pid"
 
# check lock
if [ -f $lockFile ] && . $lockFile && ps -p $PID >/dev/null && [ "$PROG" = "${0##*/}" ]; then
  echo "ERROR: $PROG already started at $TIME by $OWNER on $TTY. Nothing done, exiting..."
  exit 1
fi
 
# set lock
ps -p $$ --no-header -o user,pid,comm,stime,tty | awk '{printf "OWNER=%s;PID=%s;PROG=%s;TIME=%s;TTY=%s",$1,$2,$3,$4,$5}' > $lockFile
chmod 666 $lockFile
 
# script ...
 
# end
rm -f $lockFile
exit 0

Optimisation porte sur:
- suppressions des programmes extérieurs inutiles (basename, cat, awk, ls etc...)
- suppression d'un rm inutile puisque le ficher sémaphore est écrasé plus bas.
- ajout d'un exit 0 pour sortir proprement (bonne habitude si on chaîne des scripts)

Bashisme: Ubuntu, Debian et toute la famille UNIX poussent à l'utilisation de scripts POSIX pour des raisons de portabilité. Quand il est possible de se passer des bashismes, autant le faire. Le seul bashisme que j'ai trouvé est la structure [[ $a == $b ]]. Si, par contre, ton script a besoin des tableaux et autres facilités des shell plus "riches" comme bash, ksh et zsh, rien ne t'empêchera d'utiliser la partie sémaphore POSIX.

A voir...

[jmelyn]

Merci Ripat de partager de ton expérience.

• OK pour le Bashisme.
• Optimisation très intéressante, notamment de sourcer le fichier pour obtenir les informations plutôt que de les chercher tant bien que mal. Mon utilisation de ps était très rudimentaire!
• C'est vrai qu'il est inutile de supprimer le fichier de lock.

Je vais de ce pas modifier mes scripts... Enfin j'attendrai lundi quand même!

[syjis]

En créant de multiples scripts, j'ai eu envie des créer de l'aide en ligne, d'afficher leur version, ou de les lancer en version debug, plus certaines particularités pour certains scripts. La commande getops fût la bienvenue. Plusieurs étapes ont vu le jour dans mon idée, dont voici la première :
- mutualisation des options dites « communes » (ex : -h, -x) en les incluant dans un script de style bibliothèque.

Mutualisation des options :

Ci-dessous, la commande getops lançant la bibliothèque d'options communes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
while getopts abcdefghijklmnopqrstivwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ OPTION
do
   case $OPTION in
           a) f_a_all 	# traitements (ici lancement de la function f_a_all)
               ;;
           *) . /usr/expl/proc/BIBLIOTHEQUES/getopts.lib
               ;;
    esac
done

La bibliothèque des options communes (getopts.lib) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
case $OPTION in
    h) help 	# traitements (ici lancement de la function help)
        ;;
    v) version	# traitements (ici lancement de la function version)
        ;;
    x) set –x	# traitements (ici set –x)
         ;;
    *) echo "Erreur : l'option courte \"$OPTION\" est inexistante"
        exit
esac

PS : dans cette exemple, les options a, h, v et x sont reconnues. Les autres options afficheront :
l'option courte \"$OPTION\" est inexistante"

Attention : la bibliothèque doit être lancée avec le point devant « . »

Dans cet exemple, nous pouvons utiliser l'option -x au lieu d'ajouter la commande "set -x" dans le script et évite son modification.

Cela permet une plus grande souplesse dans les ajouts, modifications ou suppressions d'options communes (ex : ajout d'options longues dans ma seconde étape).

[syjis]

Nous voilà dans ma seconde étape, afin de pallier au problème des options longues, j'ai recours à l'utilisation du tiret comme option. Je ne suis pas le premier à trouver une solution, mais voici ma solution (en 2 points):
- ajout d'une option acceptant les arguments "-:"
- utilisation de la commande case pour les options longues

getopts dans le script :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
while getopts abcdefghijklmnopqrstivwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ-: OPTION
do
   case $OPTION in
      a) f_a_all 		# Lancement de function f_a_all
               ;;
      d) f_b_description	# Lancement de function f_d_description
	    ;;
       -) case $OPTARG in
              all) f_a_all	# Lancement de la function f_a_all
                    ;;
     description) f_b_description   # Lancement de function f_d_description
	    	      ;;
                  *) . /usr/expl/proc/BIBLIOTHEQUES/getopts.lib
                      ;;
                esac
           *) . /usr/expl/proc/BIBLIOTHEQUES/getopts.lib
               ;;
    esac
done

et pour les options communes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
case $OPTION in
    h) help 	# traitements (ici lancement de la function help)
        ;;
    x) set –x	# traitements (ici set –x)
         ;;
         -) case $OPTARG in
         debug) set -x
                    ;;
            help) help
                    ;;
                *) echo "Erreur : l'option longue \"$OPTARG\" est inexistante"
                    exit
                    ;;
       esac
   *) echo "Erreur : l'option longue \"$OPTARG\" est inexistante"
       exit
       ;;
esac

La troisième et dernière étape sera "getops en ksh - les options longues avec arguments".

[syjis]

Nous voici donc dans la troisième étape (complément des options longues sans arguments) :

Afin de pouvoir récupérer les arguments des options longues, il faut prétraiter les paramètres afin de les avoir sur plusieurs lignes (au lieu d’une seule). L’action d’aller à la ligne doit se faire uniquement lorsque nous rencontrons un tirer « - »

Prétraitement avant getopts :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
for i in $*
do
    if [ "$(echo $i | cut -c1)" = "-" ]
    then
       PARAMETRES="$PARAMETRES\n$i"
    else
       PARAMETRES="$PARAMETRES $i"
     fi
done

Cela nous permet, dans l’exemple ci-dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
courriel --objet "TEST" --message "Ceci est un test" --destinataire "toto@huit.fr"
 
echo $PARAMETRES
--objet TEST
--message Ceci est un test
--destinataire toto@huit.fr

Il suffit ensuite de lui passer un grep en prenant à partir du second champ, comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
-) case $OPTARG in
 destinataire*) CIBLE=$(echo $PARAMETRES | grep "\-\-destinataire" | cut -d" " -f2-)
                shift
                ;;
       message) MESSAGE="$(echo $PARAMETRES | grep "\-\-message" | cut -d" " -f2-)"
                shift
                ;;
         objet) OBJET="$(echo $PARAMETRES | grep "\-\-objet" | cut -d" " -f2-)"
                shift
                ;;
esac

et le tour est joué !!!!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
echo $CIBLE
toto@huit.fr
 
echo $MESSAGE
Ceci est un test
 
echo $OBJET
TEST

[chardclo]

Bonjour,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
echo ${MAVAR:?} > /dev/null

ou plus simplement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

: ${MAVAR:?}

[Sve@r]

Bonjour

Problème:
La plupart de mes scripts prennent un ou des fichiers en entrée, travaillent les données de multiples façons et donnent un ou plusieurs fichiers en sortie. Les traitements peuvent être long et complexes et nécessitent souvent plusieurs traitements à la suite. J'utilise donc des fichiers temporaires. Le problème est le nommage de ces fichiers, ainsi que leur nettoyage. Où les mettre? Dans le répertoire du (des) fichiers d'entrée, de sortie?

Solution:
Comme les autres personnes (admins) n'apprécient pas avoir des fichiers temporaires noyant les fichiers importants, j'évite absolument de mélanger les fichiers: il suffit qu'un script soit tué pour avoir des fichiers temporaires partout. Comme la petite plaquette aux toilettes l'indique: "Vous êtes prié de laisser l'endroit aussi propre que vous l'avez trouvé en entrant", faut bien ranger après. Donc /tmp est un bon candidat pour les fichiers temporaires. Néanmoins, si deux admins lancent le même script en même temps, il risque d'y avoir mélange de pinceaux. Voici finalement ce que j'utilise le plus souvent possible.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

tmpDir=$(mktemp -d /tmp/$(basename $0).XXX)

Donc je mets tous mes fichiers temporaires dans /tmp/<nom_script>.XXX. Le nom du script est évidemment utile pour comprendre d'où vient ce répertoire, les XXX sont trois caractères aléatoires pour éviter les conflits entre plusieurs exécutions simultanées. Le possesseur du répertoire est celui qui a lancé le script.

Peut-être utiliser "$$" qui donne le pid du process généré par le script en cours ce qui évite les conflits sans avoir à générer "XXX" soi-même (ne réinvontons pas le fil à couper l'eau tiède). Et (évolution) désormais nos homes possèdent par défaut un "tmp" permettant de ne pas taper dans /tmp...

Nous voici donc dans la troisième étape (complément des options longues sans arguments) :

Oui, en 2009 peut-être. Aujourd'hui getopt et getopts gèrent parfaitement les options longues...

[N_BaH]

pas le getopts de bash; il faut encore un peu bricoler derrière.

[disedorgue]

Pour revenir sur la création de fichiers temporaire qui peuvent continuer à exister suite sortie intempestive du script.

Il existe des solutions pour ce genre de problème que l'on oublie souvent dont la principale est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

trap "{ rm -f fichier; }" EXIT

Ligne que l'on met en début de script, qui effacera "fichier" en cas de CTRL-C ou de sortie du script.
Ceci ne résout pas le cas du SIGKILL (-9) mais en principe, ce cas est très rare ou devrait l'être.

Une autre méthode, est d'ouvrir le fichier et une fois celui-ci ouvert de l'effacer (sans le fermer). Dans ce cas, le fichier cessera d'exister totalement à la mort du process.

[Dens1]

Non, si y'a -i, -fi demande quand-même la confirmation. Mais la question est biaisée, dans un script les alias ne sont utilisés donc le /bin/rm et \rm ne servent pas dans un script.

Pourquoi les alias ne seraient pas utilisés dans un script ? C'est justement là (AMHA) le souci de ce post http://www.developpez.net/forums/d21...-bash_profile/