bash
bash
Le livre de recettes
C
ARL
A
LBING
, JP V
OSSEN
ET
C
AMERON
N
EWHAM
Traduction de F
RANÇOIS
C
ERBELLE
et H
ERVÉ
S
OULARD
Cambridge • Cologne • Farnham • Paris • Pékin • Sebastopol • Taipei • Tokyo
Éditions O’REILLY 18 rue Séguier 75006 Paris [email protected] http://www.oreilly.fr/L’édition originale de ce livre a été publiée aux États-Unis par O’Reilly Media Inc. sous le titre bash Cookbook, ISBN 0-596-52678-4.
© O’Reilly Media Inc., 2007
Couverture conçue par Karen MONTGOMERY et Marcia FRIEDMAN
Édition française : Dominique BURAUD
Les programmes figurant dans ce livre ont pour but d’illustrer les sujets traités. Il n’est donné aucune garantie quant à leur fonctionnement une fois compilés, assemblés ou interprétés dans le cadre d’une utilisation professionnelle ou commerciale.
© ÉDITIONS O’REILLY, Paris, 2007 ISBN 10 : 2-35402-083-X
ISBN 13 : 978-2-35402-083-5
Version papier : http://www.oreilly.fr/catalogue/2841774473
Toute représentation ou reproduction, intégrale ou partielle, faite sans le consentement de l’auteur, de ses ayants droit, ou ayants cause, est illicite (loi du 11 mars 1957, alinéa 1er de l’article 40). Cette repré-sentation ou reproduction, par quelque procédé que ce soit, constituerait une contrefaçon sanctionnée par les articles 425 et suivants du Code pénal. La loi du 11 mars 1957 autorise uniquement, aux termes des alinéas 2 et 3 de l’article 41, les copies ou reproductions strictement réservées à l’usage privé du co-piste et non destinées à une utilisation collective d’une part et, d’autre part, les analyses et les courtes citations dans un but d’exemple et d’illustration.
Table des matières
Préface ... xv
1. Débuter avec bash ... 1
1.1. Comprendre l’invite de commandes ... 4
1.2. Afficher son emplacement ... 5
1.3. Chercher et exécuter des commandes ... 6
1.4. Obtenir des informations sur des fichiers ... 8
1.5. Afficher tous les fichiers cachés ... 10
1.6. Protéger la ligne de commande ... 12
1.7. Utiliser ou remplacer des commandes ... 14
1.8. Déterminer si le shell est en mode interactif ... 15
1.9. Faire de bash le shell par défaut ... 16
1.10. Obtenir bash pour Linux ... 18
1.11. Obtenir bash pour xBSD ... 21
1.12. Obtenir bash pour Mac OS X ... 22
1.13. Obtenir bash pour Unix ... 23
1.14. Obtenir bash pour Windows ... 24
1.15. Obtenir bash sans l’installer ... 25
1.16. Documentation de bash ... 26
2. Sortie standard ... 31
2.1. Écrire la sortie sur le terminal ou une fenêtre ... 32
2.2. Écrire la sortie en conservant les espaces ... 33
2.3. Mettre en forme la sortie ... 34
2.4. Écrire la sortie sans le saut de ligne ... 35
2.5. Enregistrer la sortie d’une commande ... 36
vi Table des matières
2.7. Enregistrer la sortie de la commande ls ... 38
2.8. Envoyer la sortie et les erreurs vers des fichiers différents ... 39
2.9. Envoyer la sortie et les erreurs vers le même fichier ... 40
2.10. Ajouter la sortie à un fichier existant ... 41
2.11. Utiliser seulement le début ou la fin d’un fichier ... 42
2.12. Sauter l’en-tête d’un fichier ... 43
2.13. Oublier la sortie ... 43
2.14. Enregistrer ou réunir la sortie de plusieurs commandes ... 44
2.15. Relier une sortie à une entrée ... 46
2.16. Enregistrer une sortie redirigée vers une entrée ... 47
2.17. Connecter des programmes en utilisant la sortie comme argument 49 2.18. Placer plusieurs redirections sur la même ligne ... 50
2.19. Enregistrer la sortie lorsque la redirection semble inopérante ... 51
2.20. Permuter STDERR et STDOUT ... 53
2.21. Empêcher l’écrasement accidentel des fichiers ... 54
2.22. Écraser un fichier à la demande ... 56
3. Entrée standard ... 59
3.1. Lire les données d’entrée depuis un fichier ... 59
3.2. Conserver les données avec le script ... 60
3.3. Empêcher un comportement étrange dans un here document ... 61
3.4. Indenter un here document ... 63
3.5. Lire l’entrée de l’utilisateur ... 64
3.6. Attendre une réponse Oui ou Non ... 65
3.7. Choisir dans une liste d’options ... 68
3.8. Demander un mot de passe ... 69
4. Exécuter des commandes ... 71
4.1. Lancer n’importe quel exécutable ... 71
4.2. Connaître le résultat de l’exécution d’une commande ... 73
4.3. Exécuter plusieurs commandes à la suite ... 75
4.4. Exécuter plusieurs commandes à la fois ... 76
4.5. Déterminer le succès d’une commande ... 77
4.6. Utiliser moins d’instructions if ... 78
4.7. Lancer de longues tâches sans surveillance ... 79
4.8. Afficher des messages en cas d’erreur ... 80
4.9. Exécuter des commandes placées dans une variable ... 81
4.10. Exécuter tous les scripts d’un répertoire ... 82
5. Variables du shell ... 85
5.1. Documenter un script ... 87
5.2. Incorporer la documentation dans les scripts ... 88
Table des matières vii
5.4. Séparer les noms de variables du texte environnant ... 92
5.5. Exporter des variables ... 92
5.6. Afficher les valeurs de toutes les variables ... 94
5.7. Utiliser des paramètres dans un script ... 95
5.8. Parcourir les arguments d’un script ... 96
5.9. Accepter les paramètres contenant des espaces ... 97
5.10. Accepter des listes de paramètres contenant des espaces ... 99
5.11. Compter les arguments ... 101
5.12. Extraire certains arguments ... 103
5.13. Obtenir des valeurs par défaut ... 104
5.14. Fixer des valeurs par défaut ... 105
5.15. Utiliser null comme valeur par défaut valide ... 106
5.16. Indiquer une valeur par défaut variable ... 107
5.17. Afficher un message d’erreur pour les paramètres non définis ... 108
5.18. Modifier certaines parties d’une chaîne ... 109
5.19. Utiliser les tableaux ... 111
6. Logique et arithmétique ... 113
6.1. Utiliser l’arithmétique dans un script ... 113
6.2. Conditionner l’exécution du code ... 116
6.3. Tester les caractéristiques des fichiers ... 119
6.4. Tester plusieurs caractéristiques ... 122
6.5. Tester les caractéristiques des chaînes ... 123
6.6. Tester l’égalité ... 124
6.7. Tester avec des correspondances de motifs ... 126
6.8. Tester avec des expressions régulières ... 127
6.9. Modifier le comportement avec des redirections ... 130
6.10. Boucler avec while ... 131
6.11. Boucler avec read ... 133
6.12. Boucler avec un compteur ... 135
6.13. Boucler avec des valeurs en virgule flottante ... 136
6.14. Réaliser des branchements multiples ... 137
6.15. Analyser les arguments de la ligne de commande ... 139
6.16. Créer des menus simples ... 142
6.17. Modifier l’invite des menus simples ... 143
6.18. Créer une calculatrice NPI simple ... 144
6.19. Créer une calculatrice en ligne de commande ... 147
7. Outils shell intermédiaires I ... 149
7.1. Rechercher une chaîne dans des fichiers ... 150
7.2. Garder uniquement les noms de fichiers ... 151
7.3. Obtenir une réponse vrai/faux à partir d’une recherche ... 152
viii Table des matières
7.5. Effectuer une recherche dans un tube ... 154
7.6. Réduire les résultats de la recherche ... 156
7.7. Utiliser des motifs plus complexes dans la recherche ... 157
7.8. Rechercher un numéro de sécu ... 158
7.9. Rechercher dans les fichiers compressés ... 159
7.10. Garder une partie de la sortie ... 160
7.11. Conserver une partie d’une ligne de sortie ... 161
7.12. Inverser les mots de chaque ligne ... 162
7.13. Additionner une liste de nombres ... 163
7.14. Compter des chaînes ... 164
7.15. Afficher les données sous forme d’histogramme ... 166
7.16. Afficher un paragraphe de texte après une phrase trouvée ... 168
8. Outils shell intermédiaires II ... 171
8.1. Trier votre affichage ... 171
8.2. Trier les nombres ... 172
8.3. Trier des adresses IP ... 173
8.4. Couper des parties de la sortie ... 176
8.5. Retirer les lignes identiques ... 177
8.6. Compresser les fichiers ... 178
8.7. Décompresser des fichiers ... 180
8.8. Vérifier les répertoires contenus dans une archive tar ... 182
8.9. Substituer des caractères ... 183
8.10. Changer la casse des caractères ... 184
8.11. Convertir les fichiers DOS au format Linux/Unix ... 185
8.12. Supprimer les guillemets ... 186
8.13. Compter les lignes, les mots ou les caractères dans un fichier ... 187
8.14. Reformater des paragraphes ... 188
8.15. Aller plus loin avec less ... 189
9. Rechercher des fichiers avec find, locate et slocate ... 191
9.1. Retrouver tous vos fichiers MP3 ... 191
9.2. Traiter les noms de fichiers contenant des caractères étranges ... 193
9.3. Accélérer le traitement des fichiers trouvés ... 194
9.4. Suivre les liens symboliques ... 195
9.5. Retrouver des fichiers sans tenir compte de la casse ... 195
9.6. Retrouver des fichiers d’après une date ... 196
9.7. Retrouver des fichiers d’après leur type ... 197
9.8. Retrouver des fichiers d’après leur taille ... 198
9.9. Retrouver des fichiers d’après leur contenu ... 199
9.10. Retrouver rapidement des fichiers ou du contenu ... 200
9.11. Retrouver un fichier à partir d’une liste d’emplacements possibles ... 202
Table des matières ix
10. Autres fonctionnalités pour les scripts ... 207
10.1. Convertir un script en démon ... 207
10.2. Réutiliser du code ... 208
10.3. Utiliser des fichiers de configuration dans un script ... 210
10.4. Définir des fonctions ... 211
10.5. Utiliser des fonctions : paramètres et valeur de retour ... 213
10.6. Intercepter les signaux ... 215
10.7. Redéfinir des commandes avec des alias ... 219
10.8. Passer outre les alias ou les fonctions ... 221
11. Dates et heures ... 223
11.1. Formater les dates en vue de leur affichage ... 224
11.2. Fournir une date par défaut ... 225
11.3. Calculer des plages de dates ... 227
11.4. Convertir des dates et des heures en secondes depuis l’origine ... 230
11.5. Convertir des secondes depuis l’origine en dates et heures ... 231
11.6. Déterminer hier ou demain en Perl ... 232
11.7. Calculer avec des dates et des heures ... 233
11.8. Gérer les fuseaux horaires, les horaires d’été et les années bissextiles ... 235
11.9. Utiliser date et cron pour exécuter un script au nème jour ... 235
12. Tâches utilisateur sous forme de scripts shell ... 239
12.1. Afficher une ligne de tirets ... 239
12.2. Présenter des photos dans un album ... 241
12.3. Charger votre lecteur MP3 ... 247
12.4. Graver un CD ... 251
12.5. Comparer deux documents ... 254
13. Analyses et tâches similaires ... 257
13.1. Analyser les arguments d’un script ... 257
13.2. Afficher ses propres messages d’erreur lors de l’analyse ... 260
13.3. Analyser du contenu HTML ... 262
13.4. Placer la sortie dans un tableau ... 264
13.5. Analyser la sortie avec une fonction ... 265
13.6. Analyser du texte avec read ... 266
13.7. Analyser avec read dans un tableau ... 267
13.8. Déterminer le bon accord ... 268
13.9. Analyser une chaîne caractère par caractère ... 269
13.10. Nettoyer une arborescence SVN ... 270
13.11. Configurer une base de données MySQL ... 271
13.12. Extraire certains champs des données ... 273
x Table des matières
13.14. Supprimer les espaces ... 277
13.15. Compacter les espaces ... 281
13.16. Traiter des enregistrements de longueur fixe ... 283
13.17. Traiter des fichiers sans sauts de ligne ... 285
13.18. Convertir un fichier de données au format CSV ... 287
13.19. Analyser un fichier CSV ... 288
14. Scripts sécurisés ... 291
14.1. Éviter les problèmes de sécurité classiques ... 293
14.2. Éviter l’usurpation de l’interpréteur ... 294
14.3. Définir une variable $PATH sûre ... 294
14.4. Effacer tous les alias ... 296
14.5. Effacer les commandes mémorisées ... 297
14.6. Interdire les fichiers core ... 298
14.7. Définir une variable $IFS sûre ... 298
14.8. Définir un umask sûr ... 299
14.9. Trouver les répertoires modifiables mentionnés dans $PATH ... 300
14.10. Ajouter le répertoire de travail dans $PATH ... 303
14.11. Utiliser des fichiers temporaires sécurisés ... 304
14.12. Valider l’entrée ... 308
14.13. Fixer les autorisations ... 310
14.14. Afficher les mots de passe dans la liste des processus ... 311
14.15. Écrire des scripts setuid ou setgid ... 312
14.16. Restreindre les utilisateurs invités ... 314
14.17. Utiliser un environnement chroot ... 316
14.18. Exécuter un script sans avoir les privilèges de root ... 317
14.19. Utiliser sudo de manière plus sûre ... 318
14.20. Utiliser des mots de passe dans un script ... 319
14.21. Utiliser SSH sans mot de passe ... 321
14.22. Restreindre les commandes SSH ... 329
14.23. Déconnecter les sessions inactives ... 331
15. Scripts élaborés ... 333
15.1. Trouver bash de manière portable ... 334
15.2. Définir une variable $PATH de type POSIX ... 335
15.3. Développer des scripts shell portables ... 337
15.4. Tester des scripts sous VMware ... 339
15.5. Écrire des boucles portables ... 340
15.6. Écrire une commande echo portable ... 342
15.7. Découper l’entrée si nécessaire ... 345
15.8. Afficher la sortie en hexadécimal ... 346
15.9. Utiliser la redirection du réseau de bash ... 348
Table des matières xi
15.11. Obtenir l’entrée depuis une autre machine ... 354
15.12. Rediriger la sortie pour toute la durée d’un script ... 356
15.13. Contourner les erreurs « liste d’arguments trop longue » ... 357
15.14. Journaliser vers syslog depuis un script ... 359
15.15. Envoyer un message électronique depuis un script ... 360
15.16. Automatiser un processus à plusieurs phases ... 363
16. Configurer bash ... 367
16.1. Options de démarrage de bash ... 368
16.2. Personnaliser l’invite ... 368
16.3. Modifier définitivement $PATH ... 376
16.4. Modifier temporairement $PATH ... 377
16.5. Définir $CDPATH ... 383
16.6. Raccourcir ou modifier des noms de commandes ... 385
16.7. Adapter le comportement et l’environnement du shell ... 386
16.8. Ajuster le comportement de readline en utilisant .inputrc ... 387
16.9. Créer son répertoire privé d’utilitaires ... 389
16.10. Utiliser les invites secondaires : $PS2, $PS3 et $PS4 ... 390
16.11. Synchroniser l’historique du shell entre des sessions ... 392
16.12. Fixer les options de l’historique du shell ... 393
16.13. Concevoir une meilleure commande cd ... 396
16.14. Créer un nouveau répertoire et y aller avec une seule commande 398 16.15. Aller au fond des choses ... 399
16.16. Étendre bash avec des commandes internes chargeables ... 400
16.17. Améliorer la complétion programmable ... 406
16.18. Utiliser correctement les fichiers d’initialisation ... 411
16.19. Créer des fichiers d’initialisation autonomes et portables ... 414
16.20. Commencer une configuration personnalisée ... 416
17. Maintenance et tâches administratives ... 429
17.1. Renommer plusieurs fichiers ... 429
17.2. Utiliser GNU Texinfo et Info sous Linux ... 431
17.3. Dézipper plusieurs archives ZIP ... 432
17.4. Restaurer des sessions déconnectées avec screen ... 433
17.5. Partager une unique session bash ... 435
17.6. Enregistrer une session complète ou un traitement par lots ... 437
17.7. Effacer l’écran lorsque vous vous déconnectez ... 438
17.8. Capturer les méta-informations des fichiers pour une restauration 439 17.9. Indexer de nombreux fichiers ... 440
17.10. Utiliser diff et patch ... 441
17.11. Compter les différences dans des fichiers ... 446
17.12. Effacer ou renommer des fichiers dont le nom comporte des caractères spéciaux ... 448
xii Table des matières
17.13. Insérer des en-têtes dans un fichier ... 449
17.14. Éditer un fichier sans le déplacer ... 452
17.15. Utiliser sudo avec un groupe de commandes ... 454
17.16. Trouver les lignes présentes dans un fichier mais pas dans un autre ... 456
17.17. Conserver les N objets les plus récents ... 460
17.18. Filtrer la sortie de ps sans afficher le processus grep ... 463
17.19. Déterminer si un processus s’exécute ... 464
17.20. Ajouter un préfixe ou un suffixe à l’affichage ... 465
17.21. Numéroter les lignes ... 467
17.22. Écrire des séquences ... 469
17.23. Émuler la commande DOS pause ... 471
17.24. Formater les nombres ... 472
18. Réduire la saisie ... 475
18.1. Naviguer rapidement entre des répertoires quelconques ... 475
18.2. Répéter la dernière commande ... 477
18.3. Exécuter une commande similaire ... 478
18.4. Effectuer des substitutions sur plusieurs mots ... 479
18.5. Réutiliser des arguments ... 480
18.6. Terminer les noms automatiquement ... 481
18.7. Assurer la saisie ... 482
19. Bourdes du débutant ... 485
19.1. Oublier les autorisations d’exécution ... 485
19.2. Résoudre les erreurs « Aucun fichier ou répertoire de ce type » .... 486
19.3. Oublier que le répertoire de travail n’est pas dans $PATH ... 488
19.4. Nommer un script « test » ... 489
19.5. S’attendre à pouvoir modifier les variables exportées ... 490
19.6. Oublier des guillemets lors des affectations ... 491
19.7. Oublier que la correspondance de motifs trie par ordre alphabétique ... 493
19.8. Oublier que les tubes créent des sous-shells ... 493
19.9. Réinitialiser le terminal ... 496
19.10. Supprimer des fichiers avec une variable vide ... 497
19.11. Constater un comportement étrange de printf ... 497
19.12. Vérifier la syntaxe d’un script bash ... 499
19.13. Déboguer des scripts ... 500
19.14. Éviter les erreurs « commande non trouvée » avec les fonctions ... 502
19.15. Confondre caractères génériques du shell et expressions régulières ... 503
Table des matières xiii
A. Listes de référence ... 505
B. Exemples fournis avec bash ... 559
C. Analyse de la ligne de commande ... 569
D. Gestion de versions ... 575
E. Compiler bash ... 597
Préface
Tout système d’exploitation moderne dispose d’un interpréteur de commandes (un
shell), voire même de plusieurs. Certains shells sont orientés ligne de commande,
me celui étudié dans ce livre, tandis que d’autres offrent une interface graphique, com-me l’Explorateur de Windows ou le Finder du Mac. Certaines personnes utiliseront l’interpréteur de commande uniquement pour lancer leur application préférée et n’y retourneront qu’à la fermeture de leur session. Cependant, les interactions entre l’utili-sateur et le shell sont généralement plus fréquentes et plus élaborées. Mieux vous con-naîtrez votre shell, plus vous serez rapide et efficace.
Que vous soyez administrateur système, programmeur ou simple utilisateur, un script shell pourra, dans certaines occasions, vous faire gagner du temps ou faciliter la répéti-tion d’une tâche importante. Même la définirépéti-tion d’un simple alias, qui modifie ou rac-courcit le nom d’une commande souvent utilisée, peut avoir un effet substantiel. Nous allons nous intéresser, entre autres, à tous ces aspects.
Comme c’est le cas avec tout langage de programmation général, il existe plusieurs ma-nières d’effectuer une tâche. Parfois, il n’existe qu’une seule bonne manière, mais, le plus souvent, vous avez le choix entre deux ou trois approches équivalentes. Celle que vous choisissez dépend de votre style personnel, de votre créativité et de votre connaissance des différentes commandes et techniques. Cela s’applique aussi bien à nous, en tant qu’auteurs, qu’à vous, en tant que lecteur. Dans la plupart des exemples, nous propo-sons une seule méthode et la mettons en œuvre. Parfois, nous optons pour une métho-de particulière et expliquons pourquoi nous pensons qu’il s’agit métho-de la meilleure. Nous présenterons, à l’occasion, plusieurs solutions équivalentes afin que vous puissiez choi-sir celle qui correspond le mieux à vos besoins et à votre environnement.
Quelquefois, vous devrez choisir entre un code efficace très astucieux et un code plus lisible. Nous nous tournons toujours vers le code le plus lisible. En effet, l’expérience nous a appris que la lisibilité du code astucieux écrit aujourd’hui n’est plus la même 6 ou 18 mois et 10 projets plus tard. Vous risquez alors de passer beaucoup de temps à vous interroger sur le fonctionnement de votre code. Faites-nous confiance : écrivez du code clair et bien documenté. Vous vous en féliciterez plus tard.
xvi Préface
Notre public
Ce livre est destiné aux utilisateurs de systèmes Unix ou Linux (et Mac compris), ainsi qu’aux administrateurs qui peuvent se trouver chaque jour devant plusieurs systèmes différents. Il vous aidera à créer des scripts qui vous permettront d’en faire plus, en moins de temps, plus facilement et de manière plus cohérente que jamais.
Les utilisateurs débutants apprécieront les sections qui concernent l’automatisation des tâches répétitives, les substitutions simples et la personnalisation de leur environne-ment afin qu’il soit plus agréable et peut-être plus conforme à leurs habitudes. Les uti-lisateurs expérimentés et les administrateurs trouveront de nouvelles solutions et des approches différentes à des tâches courantes. Les utilisateurs avancés seront intéressés par tout un ensemble de techniques utilisables sur-le-champ, sans devoir se souvenir de tous les détails syntaxiques.
Cet ouvrage s’adresse particulièrement :
• aux néophytes d’Unix ou de Linux qui ont peu de connaissances du shell, mais qui souhaitent dépasser la seule utilisation de la souris ;
• aux utilisateurs d’Unix ou de Linux expérimentés et aux administrateurs système qui recherchent des réponses rapides à leurs questions concernant l’écriture de scripts shell ;
• aux programmeurs travaillant dans un environnement Unix ou Linux (ou même Windows) qui veulent améliorer leur productivité ;
• aux administrateurs système qui débutent sous Unix ou Linux ou qui viennent d’un environnement Windows et qui doivent se former rapidement ;
• aux utilisateurs de Windows et les administrateurs système expérimentés qui sou-haitent disposer d’un environnement puissant pour l’exécution de scripts.
Ce livre ne s’attardera pas longtemps sur les bases de l’écriture de scripts shell. Pour ce-la, consultez Le shell bash de Cameron Newham (Éditions O’Reilly) et Introduction aux
scripts shell de Nelson H.F. Beebe et Arnold Robbins (Éditions O’Reilly). Notre objectif
est d’apporter des solutions aux problèmes classiques, en insistant sur la pratique et non sur la théorie. Nous espérons que ce livre vous fera gagner du temps lorsque vous rechercherez une solution ou essaierez de vous souvenir d’une syntaxe. En réalité, ce sont les raisons de la rédaction de cet ouvrage. Nous voulions un livre qui propose des idées et permette de passer directement aux exemples pratiques opérationnels en cas de besoin. Ainsi, nous n’avons pas à mémoriser les différences subtiles entre le shell, Perl, C, etc.
Nous supposons que vous avez accès à un système Unix ou Linux (ou bien, reportez-vous à la recette 1.15, page 25, ou à la recette 15.4, page 339) et que reportez-vous savez comment ouvrir une session, saisir des commandes basiques et utiliser un éditeur de texte. Pour la majorité des exemples, vous n’aurez pas besoin des droits du super-utilisateur (root). En revanche, ils seront indispensables pour quelques-uns, notamment ceux qui concer-nent l’installation de bash.
Préface xvii
Contenu de ce livre
Le sujet de cet ouvrage est bash, le GNU Bourne Again Shell. Il fait partie de la famille des shells Bourne, dont les autres membres sont le shell Bourne originel, sh, le shell Korn,
ksh, ainsi que sa version pdksh (Public Domain Korn Shell). Bien qu’ils ne soient pas au
cœur de ce livre, tout comme dash et zsh, les scripts présentés fonctionneront assez bien avec ces autres interpréteurs de commandes.
Vous pouvez lire cet ouvrage du début à la fin ou l’ouvrir et sélectionner ce qui retient votre attention. Cela dit, nous espérons surtout que dès que vous aurez une question sur la manière d’effectuer une tâche ou besoin d’un conseil, vous pourrez trouver faci-lement la réponse adaptée (ou proche) et économiser du temps et des efforts.
La philosophie Unix tend à construire des outils simples qui répondent parfaitement à des problèmes précis, puis à les combiner selon les besoins. L’association des outils se fait généralement au travers d’un script shell car ces commandes, appelées tubes, peu-vent être longues et difficiles à mémoriser ou à saisir. Lorsque ce sera nécessaire, nous emploierons ces outils dans le contexte d’un script shell pour réunir les différents élé-ments qui permettent d’atteindre l’objectif visé.
Ce livre a été écrit avec OpenOffice.org Writer sur la machine Linux ou Windows dis-ponible à un moment donné et en utilisant Subversion (voir l’annexe D, Gestion de
ver-sions). Grâce au format ODF (Open Document Format), de nombreux aspects de l’écriture
de ce livre, comme les références croisées et l’extraction de code, ont été simplifiés (voir la recette 13.17, page 285).
Logiciel GNU
bash, ainsi que d’autres outils mentionnés dans ce livre, font partie du projet GNU
(http://www.gnu.org/). GNU est un acronyme récursif qui signifie en anglais GNU’s Not
Unix (GNU n’est pas Unix). Démarré en 1984, ce projet a pour objectif de développer
un système d’exploitation de type Unix libre.
Sans trop entrer dans les détails, ce que l’on nomme couramment Linux est, en réalité, un noyau avec un ensemble minimal de différents logiciels. Les outils GNU se placent autour de ce cœur et bons nombres d’autres logiciels peuvent être inclus selon les dis-tributions. Cependant, le noyau Linux lui-même n’est pas un logiciel GNU.
Le projet GNU défend l’idée que Linux devrait en réalité se nommer « GNU/Linux ». C’est également l’avis d’autres acteurs et certaines distributions, notamment Debian, emploie cette dénomination. Par conséquent, on peut considérer que l’objectif du pro-jet GNU a été atteint, même si le résultat n’est pas exclusivement GNU.
De nombreux logiciels importants, en particulier bash, sont issus du projet GNU et il existe des versions GNU de pratiquement tous les outils mentionnés dans ce livre. Bien que les outils fournis par ce projet soient plus riches en fonctionnalités et, en général, plus faciles à utiliser, ils sont également parfois légèrement différents. Nous reviendrons sur ce sujet à la recette 15.3, page 337, même si les fournisseurs d’Unix commerciaux, en-tre les années 1980 et 1990, sont largement responsables de ces différences.
Tous ces aspects de GNU, Unix et Linux ont déjà été traités en détail (dans des livres aus-si épais que celui-ci), mais nous pensons que ces remarques étaient nécessaires. Pour plus d’informations sur le sujet, consultez le site http://www.gnu.org.
xviii Préface
Note sur les exemples de code
Les éléments d’exécution d’un script shell sont généralement présentés de la manière suivante :
$ ls
a.out cong.txt def.conf fichier.txt autre.txt zebra.liste $
Le premier caractère est souvent un symbole dollar ($) pour indiquer que la commande a été saisie à l’invite du shell bash. (N’oubliez pas qu’elle peut être différente et que vous pouvez la modifier, comme l’explique la recette 16.2, page 368.) L’invite est affichée par l’interpréteur de commandes. C’est à vous de saisir le reste de la ligne. De manière simi-laire, la dernière ligne de ces exemples est souvent une invite (à nouveau un $) afin de montrer que l’exécution de la commande est terminée et que le contrôle est revenu au shell.
Le symbole dièse (#) pose plus de problèmes. Dans de nombreux fichiers Unix ou Linux, y compris les scripts du shell bash, ce symbole dénote le début d’un commentaire et nos exemples l’emploient ainsi. Mais, dans l’invite de bash (à la place de $), # signifie que vous avez ouvert une session en tant que root. Puisqu’un seul de nos exemples exécute ses commandes en tant que root, vous ne devriez pas être trop perturbé, mais il est im-portant que vous le sachiez.
Lorsque la chaîne d’invite est absente d’un exemple, nous montrons en réalité le conte-nu d’un script shell. Pour quelques exemples longs, nous conte-numérotons les lignes du script, mais ces numéros ne font pas partie du script lui-même.
Parfois, nous montrons un exemple sous forme d’un journal de session ou d’une suite de commandes. Nous pouvons également utiliser la commande cat avec un ou plu-sieurs fichiers afin de vous révéler le contenu du script et/ou des fichiers de données uti-lisés dans l’exemple ou dans le résultat d’une opération.
$ cat fichiers_donnees static en-tete ligne1 static en-tete ligne2 1 toto
2 titi 3 tata
De nombreux scripts et fonctions plus élaborés sont également disponibles en téléchar-gement. Pour plus de détails, reportez-vous à la section Votre avis, page xxi. Nous avons décidé d’utiliser #!/usr/bin/env bash avec ces exemples car cette déclaration est plus por-table que #!/bin/bash, que vous pourrez rencontrer sur Linux ou sur un Mac. Pour plus d’informations, consultez la recette 15.1, page 334.
Vous pourrez également remarquer la ligne suivante dans certains exemples de code : # bash Le livre de recettes : nom_extrait
Cela signifie que le code, en version américaine, est disponible en téléchargement sur le site mis en place par les auteurs pour ce livre (http://www.bashcookbook.com). Sa ver-sion francisée se trouve sur le site http://www.oreilly.fr/catalogue/2841774473. Le télé-chargement (.tgz ou .zip) est documenté, mais vous trouverez le code dans les fichiers au format ./chXX/nom_extrait, où chXX correspond au chapitre et nom_extrait au nom du fichier.
Préface xix
Utilisation inefficace de cat
Certains utilisateurs Unix aiment repréer les points d’inefficacité dans le code des autres. En général, cette critique est appréciée lorsqu’elle est donnée de manière cons-tructive.
Le cas le plus courant est probablement « l’utilisation inefficace de cat », signalé lorsque quelqu’un exécute cat fichier | grep toto à la place de grep toto fichier. Dans ce cas,
cat est inutile et implique un surcoût puisque la commande s’exécute dans un sous-shell.
Un autre cas fréquent est cat fichier | tr '[A-Z]' '[a-z]' à la place de tr '[A-Z]' '[a-z]' < fichier. Parfois, l’emploi de cat peut même provoquer le dysfonctionnement d’un script (voir la recette 19.8, page 493).
Mais, une utilisation superflue de cat sert parfois un objectif. Elle peut représenter un emplacement dans un tube que d’autres commandes remplaceront par la suite (peut-être même cat -n). D’autre part, en plaçant le fichier sur le côté gauche d’une comman-de, votre attention s’oriente plus facilement vers cette partie du code. Ce ne sera pas le cas si le fichier se trouve derrière un symbole < à l’extrémité droite de la page.
Même si nous approuvons l’efficacité, ainsi que la nécessité de la rechercher, elle n’est plus aussi essentielle qu’elle a pu l’être. Cependant, nous ne militons pas en faveur de la négligence ou de l’explosion de code. Nous disons simplement que la rapidité des pro-cesseurs n’est pas vraiment en déclin. Si vous aimez utiliser cat, n’hésitez donc pas.
Note à propos de Perl
Nous évitons volontairement l’emploi de Perl dans nos solutions, autant que possible, même si, dans certains cas, il serait le bienvenu. Perl fait déjà l’objet d’une description détaillée dans d’autres ouvrages, bien plus que nous ne pourrions le faire ici. D’autre part, Perl s’avère généralement plus long, avec un surcoût plus important, que nos so-lutions. Il existe également une mince frontière entre l’écriture de scripts shell et de scripts Perl ; le sujet de ce livre est l’écriture de scripts shell.
Les scripts shell servent à combiner des programmes Unix, tandis que Perl inclut de nombreuses fonctionnalités des programmes Unix externes dans le langage lui-même. Il est ainsi plus efficace et, d’une certaine manière, plus portable. Cependant, il est éga-lement différent et complique l’exécution efficace des programmes externes dont vous avez besoin.
Le choix de l’outil à employer est souvent plus guidé par ses connaissances de l’outil que par toute autre raison. En revanche, l’objectif est toujours de réaliser le travail ; le choix de l’outil est secondaire. Nous vous montrerons plusieurs manières de réaliser certaines opérations avec bash et des outils connexes. Lorsque votre but sera de mener à bien votre travail, vous devrez choisir les outils à utiliser.
Autres ressources
• Perl Cookbook, 3e édition, Nathan Torkington et Tom Christiansen (O’Reilly Media) ;
• Programmation en Perl, 3e édition, Larry Wall et autres (Éditions O’Reilly) ;
xx Préface
• Maîtrise des expressions régulières, 2e édition, Jeffrey E. F. Friedl (Éditions O’Reilly) ;
• Le shell Bash, 3e édition, Cameron Newham (Éditions O’Reilly) ;
• Introduction aux scripts shell, Nelson H.F. Beebe et Arnold Robbins (Éditions
O’Reilly).
Conventions typographiques
Les conventions typographiques sont les suivantes : MenuIndique des intitulés, des options et des boutons de menus, ainsi que des touches du clavier, comme Alt et Ctrl.
Italique
Désigne des termes nouveaux, des URL, des adresses électroniques, des noms de fichiers, des extensions de fichiers, des noms de chemins, des répertoires et des utili-taires Unix.
Chasse fixe
Cette police est utilisée pour les commandes, les options, les variables, les attributs, les fonctions, les types, les classes, les espaces de noms, les méthodes, les modules, les propriétés, les paramètres, les valeurs, les objets, les événements, les gestionnai-res d’événements, les balises XML, les balises HTML, les macros, le contenu des fichiers et la sortie des commandes.
Chasse fixe gras
Signifie à l’utilisateur de saisir littéralement des commandes ou du texte.
Chasse fixe italique
Montre que du texte doit être remplacé par des valeurs saisies par l’utilisateur.
Utiliser les exemples de code
Ce livre a comme objectif de vous aider. En général, vous pourrez utiliser les exemples de code sans restriction dans vos pages web et vos conceptions. Vous n’aurez pas besoin de contacter O’Reilly pour une autorisation, à moins que vous ne vouliez reproduire des portions significatives de code. La conception d’un programme reprenant plusieurs extraits de code de cet ouvrage ne requiert aucune autorisation. Par contre, la vente et la distribution d’un CD-ROM d’exemples provenant des ouvrages O’Reilly en nécessi-tent une. Répondre à une question en citant le livre et les exemples de code ne
requiè-Cette icône signifie un conseil, une suggestion ou une note générale.
Préface xxi
rent pas de permission. Par contre intégrer une quantité significative d’exemples de code extraits de ce livre, dans la documentation de vos produits en nécessite une. Nous apprécions, sans l’imposer, l’attribution de l’origine de ce code. Une attribution comprend généralement le titre, l’auteur, l’éditeur et le numéro ISBN. Par exemple, « bash Le livre de recettes, de Carl Albing, JP Vossen et Cameron Newham. Copyright 2007 Éditions O’Reilly, 2-84177-447-3 ».
Si vous pensez que l’utilisation que vous avez faite de ce code sort des limites d’une uti-lisation raisonnable ou du cadre de l’autorisation ci-dessus, n’hésitez pas à nous contac-ter à l’adresse [email protected].
Votre avis
Adressez vos commentaires et questions sur ce livre à l’éditeur : Éditions O’Reilly
18 rue Séguier 75006 Paris
Une page web existe pour ce livre, où nous donnons les exemples, une liste d’errata et quelques informations supplémentaires, à l’adresse :
http://www.oreilly.fr/catalogue/2841774473
Vous trouverez également des informations sur cet ouvrage, des exemples de code, des errata, des liens, la documentation de bash et bien d’autres compléments sur le site créé par les auteurs (en anglais) :
http://www.bashcookbook.com
Pour donner vos commentaires ou poser des questions techniques sur ce livre, envoyez un courriel à :
Pour plus d’informations sur les ouvrages, conférences, logiciels, les centres de ressour-ces et le réseau O’Reilly, rendez-vous sur le site web O’Reilly à l’adresse :
http://www.oreilly.com et http://www.oreilly.fr
Remerciements
Merci à la GNU Software Foundation et à Brian Fox pour avoir écrit bash. Merci égale-ment à Chet Ramey, qui assure le développeégale-ment de bash depuis la version 1.14 au mi-lieu des années 90. Nous lui sommes reconnaissants d’avoir répondu à nos questions et d’avoir relu une version préliminaire de ce livre.
Relecteurs
Un grand merci à nos relecteurs : Yves Eynard, Chet Ramey, William Shotts, Ryan Wal-dron et Michael Wang. Leurs commentaires, leurs suggestions et, dans certains cas, leurs solutions alternatives nous ont été indispensables. Ils ont également repéré nos erreurs et, de manière générale, amélioré cet ouvrage. Les erreurs que vous pourriez trouver nous sont dues.
xxii Préface
O’Reilly
Nous voulons remercier toute l’équipe de O’Reilly, notamment Mike Loukides, Derek Di Matteo et Laurel Ruma.
Des auteurs
Carl
L’écriture d’un livre n’est jamais un effort totalement solitaire. Merci à JP et à Cameron d’avoir travaillé avec moi sur ce projet. Nos talents complémentaires et nos disponibili-tés respectives ont permis d’écrire un livre plus abouti. Je voudrais également remercier JP pour nous avoir fourni une certaine infrastructure matérielle. Merci à Mike pour avoir accepté ma proposition de ce livre sur bash, de m’avoir mis en contact avec JP et Cameron qui avaient un projet similaire, de nous avoir poussé lorsque nous étions blo-qués et de nous avoir guidés lorsque nous devenions fous. Son assistance permanente et ses conseils techniques ont été très appréciés. Ma femme et mes enfants m’ont patiem-ment soutenu tout au long de ce projet, en m’encourageant, en me motivant et en me laissant du temps et de la place pour travailler. Je les remercie du fond du cœur. Outre la rédaction de ce livre, un travail de recherche et de préparation a été nécessaire. Je suis particulièrement redevable à Dr. Ralph Bjork qui m’a initié à Unix, bien avant que quiconque en ait entendu parler. Sa perspicacité, sa prévoyance et ses conseils m’ont été bénéfiques bien plus longtemps que je ne l’aurais imaginé.
Je dédie ce livre à mes parents, Hank et Betty, qui m’ont apporté toutes les meilleures choses qu’ils avaient à m’offrir, comme leur présence, la foi chrétienne, l’amour, une ex-cellente éducation, une place dans la vie et tout ce que l’on souhaite pour ses propres enfants. Je ne pourrais jamais les remercier assez.
JP
Merci à Cameron pour avoir écrit Le shell bash. Son livre m’a énormément appris et a été ma première référence lorsque j’ai débuté ce projet. Merci à Carl pour tout son tra-vail, sans lequel il aurait fallu quatre fois plus de temps pour un résultat inférieur. Je voudrais remercier Mike d’avoir accepté ce projet, de l’avoir aidé à avancer et d’avoir proposé à Carl de nous rejoindre. Merci également à Carl et à Mike pour leur patience quant à mes problèmes existentiels et de planning.
Je dédie ce livre à Papa, qui en aurait été très content. Il m’a toujours dit que les deux décisions les plus importantes sont ce que l’on fait et avec qui l’on se marie. En y réflé-chissant, je pense avoir plutôt bien réussi. Cet ouvrage est donc également dédié à Ka-ren, pour son incroyable soutien, patience et compréhension pendant ce processus plus long que prévu et sans qui les ordinateurs ne seraient pas aussi amusants. Enfin, merci à Kate et Sam, qui ont tellement contribué à résoudre mes problèmes d’organisation.
Cameron
J’aimerais remercier JP et Carl pour leur incroyable travail, sans lequel ce livre n’existe-rait probablement pas. Merci également à JP pour avoir émis l’idée d’un tel livre sur
bash ; je suis certain qu’il le regrette parfois, face aux longues heures passées devant le
1
Débuter avec bash
Qu’est-ce qu’un shell et pourquoi faudrait-il s’y intéresser ?
Tout système d’exploitation récent (postérieur à 1970) propose une forme d’interface utilisateur, c’est-à-dire un mécanisme permettant d’indiquer les commandes à exécuter. Dans les premiers systèmes d’exploitation, cette interface de commande était intégrée et il n’existait qu’une seule manière de converser avec l’ordinateur. Par ailleurs, l’interface ne permettait d’exécuter que des commandes, car c’était alors l’unique rôle de l’ordina-teur.
Le système d’exploitation Unix a promu la séparation du shell (l’élément du système qui permet de saisir des commandes) de tous les autres composants : le système d’entrée/sor-tie, l’ordonnanceur, la gestion de la mémoire et tous les autres aspects pris en charge par le système d’exploitation (dont la plupart des utilisateurs ne veulent pas entendre par-ler). L’interpréteur de commandes n’était qu’un programme parmi tant d’autres. Son travail était d’exécuter d’autres programmes pour le compte des utilisateurs.
Cependant, cette séparation a été le début d’une révolution. Le shell n’était qu’un autre programme qui s’exécutait sur Unix et, si vous n’aimiez pas celui livré en standard, vous pouviez écrire le vôtre. C’est ainsi qu’à la fin des dix premières années d’existence d’Unix, au moins deux shells étaient en concurrence : le shell Bourne, sh (un descendant du shell originel de Thomson), et le shell C, csh. La deuxième décennie d’Unix à vue l’apparition d’autres variantes : le shell Korn (ksh) et la première version de bash. À la fin de la troisième décennie, il existait probablement une dizaine de shells différents. Une fois devant votre système, vous demandez-vous « vais-je utiliser csh, bash ou ksh aujourd’hui » ? C’est peu probable. Vous utilisez certainement le shell standard livré avec votre système Linux (ou BSD, Mac OS X, Solaris, HP/UX). Mais, en sortant l’inter-préteur de commandes du système d’exploitation lui-même, les développeurs (comme Brian Fox, le créateur de bash, et Chet Ramey, actuellement responsable de bash) ont plus de facilité à écrire de meilleurs shells. Vous pouvez créer un nouveau shell sans tou-cher au système d’exploitation. Il est ainsi beaucoup plus facile de faire accepter un nou-veau shell, puisque les fournisseurs de systèmes d’exploitation n’ont pas à l’intégrer à leur système. Il suffit de préparer le shell afin qu’il puisse être installé sur un système comme n’importe quel autre programme.
2 Chapitre 1 — Débuter avec bash
Mais, pourquoi faire autant d’histoires pour un programme qui prend simplement des commandes et les exécute ? Effectivement, si le shell ne vous permettait que de saisir des commandes, il ne serait guère intéressant. Cependant, deux facteurs ont été prédo-minants dans l’évolution du shell Unix : la facilité d’utilisation et la programmation. Il en a résulté un shell moderne qui offre de nombreuses fonctionnalités en plus d’accep-ter des commandes.
Les shells modernes sont très pratiques. Par exemple, ils se souviennent des commandes saisies et vous permettent de les réutiliser et de les modifier. Ils vous permettent égale-ment de définir vos propres abréviations de commandes, des raccourcis et d’autres fonc-tionnalités. Pour un utilisateur expérimenté, la saisie de commandes (c’est-à-dire avec les raccourcis, les alias et la complétion) est beaucoup plus efficace et rapide que le dé-placement d’icônes au sein d’une interface graphique.
Outre leur simple commodité, les shells sont programmables. Certaines suites de com-mandes sont invoquées très souvent. Dès que vous effectuez une opération plus d’une fois, vous devez vous demander « puis-je écrire un programme qui fasse cela à ma place » ? La réponse est oui. Un shell est aussi un langage de programmation spécifique-ment conçu pour opérer avec les commandes du système de votre ordinateur. Par con-séquent, si vous souhaitez générer un millier de fichiers MP3 à partir de fichiers WAV, vous pouvez écrire un programme shell (ou un script shell) qui le fera. Si vous souhaitez compresser tous les fichiers de journalisation de votre système, vous pouvez écrire un script shell qui réalisera ce travail. Dès qu’une tâche devient répétitive, vous devez es-sayer de l’automatiser en écrivant un script shell. Il existe plusieurs langages de scripts puissants, comme Perl, Python et Ruby, mais l’interpréteur de commandes d’Unix (quelle que soit la variante du shell que vous utilisez) est un bon point de départ. En effet, vous savez déjà saisir des commandes, alors pourquoi compliquer les choses ?
Intérêt de bash
Si ce livre s’articule autour de bash et non d’un autre shell, c’est que bash est largement disponible. Il n’est pas le plus récent, sans doute pas le plus fantaisiste ni le plus puissant (quoi qu’il ne doit pas en être loin) et n’est pas le seul à être distribué comme logiciel
Open Source, mais il est omniprésent.
Les raisons en sont historiques. Les premiers shells étaient plutôt de bons outils de pro-grammation, mais ils étaient peu pratiques pour les utilisateurs. Le shell C a amélioré la facilité d’utilisation, comme la possibilité de répéter une commande déjà saisie, mais faisait un piètre langage de programmation. Le shell Korn, sorti ensuite (au début des années 80), a amélioré la facilité d’utilisation et le langage de programmation et sem-blait promis à un grand avenir. Malheureusement, ksh n’était pas initialement un logi-ciel Open Source ; il était un produit propriétaire, donc difficile à fournir avec un système d’exploitation gratuit comme Linux. Sa licence a été modifiée en 2000, puis à nouveau en 2005.
À la fin des années 80, la communauté Unix a décidé que la standardisation était une bonne chose et les groupes de travail POSIX (sous l’égide de l’IEEE) ont été formés. POSIX a normalisé les bibliothèques et les utilitaires Unix, en particulier le shell. L’in-terpréteur de commandes standard était principalement basé sur la version de 1988 du shell Korn, avec certaines caractéristiques du shell C et quelques innovations. bash a
Débuter avec bash 3
marré au sein du projet GNU, dont le but était de créer un système POSIX complet et donc un shell POSIX.
bash offrait les possibilités indispensables aux programmeurs shell, ainsi que la
commo-dité souhaitée par les utilisateurs de la ligne de commande. À l’origine, il a été conçu comme une alternative au shell Korn, mais avec l’importance prise par le mouvement du logiciel libre et la large adoption de Linux, bash a rapidement éclipsé ksh.
C’est ainsi que bash est devenu l’interpréteur de commandes par défaut de toutes les dis-tributions Linux que nous connaissons (il existe une centaine de disdis-tributions Linux et il est probable que quelques-unes choisissent un autre shell par défaut), ainsi que sur Mac OS X. Il est également disponible pour tous les autres systèmes d’exploitation Unix, notamment BSD et Solaris. Dans les rares cas où bash n’est pas livré avec le système, son installation reste simple. Il est même disponible pour Windows (via Cygwin). bash est à la fois un langage de programmation puissant et une bonne interface utilisateur. Vous n’aurez même pas à sacrifier des raccourcis clavier pour obtenir des fonctions de pro-grammation élaborées.
En vous formant à bash, vous ne pouvez pas vous tromper. Les shells par défaut les plus répandus sont l’ancien shell Bourne et bash, dont la compatibilité avec le premier est excellente. L’un de ces interpréteurs de commandes est sans aucun doute présent sur tout système d’exploitation Unix, ou assimilé, moderne. De plus, comme nous l’avons précisé, si bash est absent de votre machine, rien ne vous empêche de l’installer. Cepen-dant, il existe d’autres shells. Dans l’esprit du logiciel libre, les auteurs et les responsables de tous ces shells partagent leurs idées. Si vous consultez les rapports de modification de
bash, vous constaterez que de nombreuses caractéristiques ont été ajoutées ou ajustées
afin d’assurer une compatibilité avec un autre shell. Cependant, la plupart des utilisa-teurs s’en moquent. Ils prennent ce qui existe et s’en contentent. Par conséquent, si cela vous intéresse, vous pouvez étudier d’autres shells. Il existe de nombreuses alternatives dignes d’intérêt et vous pourriez en préférer certaines, même si elles ne seront proba-blement pas aussi répandues que bash.
Le shell bash
bash est un shell, c’est-à-dire un interpréteur de commandes. Son principal objectif,
comme celui de n’importe quel shell, est de vous permettre d’interagir avec le système d’exploitation de l’ordinateur afin d’accomplir vos tâches. En général, cela implique le lancement de programmes. Le shell prend donc les commandes saisies, détermine les programmes qui doivent être exécutés et les lance pour vous. Certaines tâches deman-dent l’exécution d’une suite d’actions récurrente ou très complexe, voire les deux. La programmation shell, ou l’écriture de scripts shell, vous permet d’automatiser ces tâ-ches, pour plus de facilité d’utilisation, de fiabilité et de reproductibilité.
Si bash est nouveau pour vous, nous commencerons par certains fondamentaux. Si vous avez déjà utilisé Unix ou Linux, vous avez probablement rencontré bash, mais peut-être sans le savoir. bash est essentiellement un langage d’exécution de commandes et celles que vous avez déjà pu saisir, comme ls, cd, grep ou cat, sont, en un sens, des commandes
bash. Parmi ces commandes, certaines sont intégrées à bash lui-même, tandis que
d’autres sont des programmes séparés. Pour le moment, cette différence n’est pas impor-tante.
4 Chapitre 1 — Débuter avec bash
Nous terminerons ce chapitre en expliquant comment obtenir bash. La plupart des sys-tèmes sont livrés avec une version de bash installée, mais ce n’est pas le cas de tous. Même si votre système vient avec bash, il est toujours bon de savoir comment l’obtenir et l’installer. De nouvelles versions, offrant de nouvelles fonctionnalités, sortent de temps à autre.
Si vous utilisez déjà bash et en avez une certaine habitude, vous pouvez aller directe-ment au chapitre 2. Vous n’êtes pas obligé de lire ce livre du début à la fin. Si vous con-sultez les recettes des chapitres centraux, vous verrez de quoi bash est réellement capable. Mais, commençons par le début.
1.1. Comprendre l’invite de commandes
Problème
Vous voulez savoir ce que signifient tous ces symboles de ponctuation.
Solution
Tous les interpréteurs de commandes possèdent une forme d’invite qui vous signale que le shell est prêt à accepter vos ordres. L’aspect de l’invite dépend de nombreux facteurs, en particulier du type et de la version du système d’exploitation, du type et de la version du shell, de la distribution et de sa configuration. Dans la famille des shells Bourne, le symbole $ à la fin de l’invite signifie généralement que vous avez ouvert une session en tant qu’utilisateur normal, tandis que le symbole # signifie que vous êtes le super-utili-sateur (root). Le compte root est l’administrateur du système et équivaut au compte
Sys-tème de Windows (plus puissant que le compte Administrateur) ou au compte Superviseur
de Netware. root est tout-puissant et peut faire tout ce qu’il veut sur un système Unix ou Linux classique.
Les invites par défaut affichent souvent le chemin du répertoire courant, même si elles peuvent l’abréger. Le symbole ~ signifie que le répertoire de travail est votre répertoire personnel. Certaines invites par défaut peuvent également afficher votre nom d’utilisa-teur et le nom de la machine sur laquelle vous êtes connecté. Si, pour le moment, cela vous semble idiot, vous changerez d’avis lorsque vous serez connecté à cinq machines sous des noms potentiellement différents.
Voici une invite Linux classique, pour l’utilisateur jp sur la machine adams, actuelle-ment dans son répertoire personnel. Le symbole $ final indique qu’il s’agit d’un utilisa-teur normal, non de root.
jp@adams:~$
En passant dans le répertoire /tmp, voici ce que devient l’invite. Vous remarquerez que ~, qui signifie en réalité /home/jp, a été remplacé par /tmp.
1.2. Afficher son emplacement 5
Discussion
L’invite du shell est un élément prédominant de la ligne de commande et ses possibilités de personnalisation sont nombreuses. Pour le moment, vous devez simplement savoir comment l’interpréter. Bien entendu, votre invite par défaut peut être différente, mais vous devez déjà être en mesure de la comprendre, au moins partiellement.
Certains systèmes Unix ou Linux offrent accès à la puissance de root par le biais de com-mandes comme su et sudo. Parfois, root n’est pas réellement tout-puissant, par exemple lorsque le système intègre une politique des accès (MAC — mandatory access control), comme SELinux de la NSA.
Voir aussi
• la recette 1.2, Afficher son emplacement, page 5 ;
• la recette 14.19, Utiliser sudo de manière plus sûre, page 318 ; • la recette 16.2, Personnaliser l’invite, page 368 ;
• la recette 17.15, Utiliser sudo avec un groupe de commandes, page 454.
1.2. Afficher son emplacement
Problème
Vous n’êtes pas certain de votre répertoire de travail et l’invite par défaut n’est d’aucune aide.
Solution
Utilisez la commande interne pwd ou définissez une invite plus utile (voir la recette 16.2, page 368). Par exemple :
bash-2.03$ pwd /tmp
bash-2.03$ export PS1='[\u@\h \w]$ ' [jp@solaris8 /tmp]$
Discussion
pwd signifie print working directory (afficher le répertoire de travail) et accepte deux
ar-guments. -L, l’option par défaut, affiche votre chemin logique. -P affiche votre empla-cement physique, qui peut être différent du chemin logique si vous avez suivi un lien symbolique.
bash-2.03$ pwd /tmp/rep2
6 Chapitre 1 — Débuter avec bash bash-2.03$ pwd -L /tmp/rep2 bash-2.03$ pwd -P /tmp/rep1
Voir aussi
• la recette 16.2, Personnaliser l’invite, page 368.
1.3. Chercher et exécuter des commandes
Problème
Vous voulez trouver et exécuter une commande précise sous bash.
Solution
Essayez les commandes type, which, apropos, locate, slocate, find et ls.
Discussion
bash gère une liste des répertoires dans lesquels il doit rechercher les commandes. Cette
liste est placée dans la variable d’environnement $PATH. La commande type interne à
bash cherche dans votre environnement (y compris les alias, les mots-clés, les fonctions,
les commandes internes et les fichiers dans $PATH) les commandes exécutables corres-pondant à ses arguments et affiche le type et l’emplacement de celles trouvées. Parmi tous ces arguments, l’option -a permet d’afficher toutes les correspondances et pas seu-lement la première. La commande which est similaire, mais sa recherche se fait unique-ment dans la variable $PATH (et les alias de csh). Elle peut être différente d’un système à l’autre (il s’agit souvent d’un script csh sur BSD et d’un binaire sur Linux), mais elle ac-cepte généralement l’option -a, tout comme type. Vous pouvez vous en servir lorsque vous connaissez le nom de la commande et souhaitez connaître son emplacement pré-cis, ou bien pour savoir si elle existe sur l’ordinateur. Par exemple :
$ type which
which is hashed (/usr/bin/which) $ type ls ls is aliased to `ls -F -h' $ type -a ls ls is aliased to `ls -F -h' ls is /bin/ls $ which which /usr/bin/which
1.3. Chercher et exécuter des commandes 7
Pratiquement toutes les commandes disposent d’une aide sur leur utilisation. En géné-ral, il existe une documentation en ligne sous forme de pages de manuel (manpages). Pour les consulter, utilisez la commande man. Par exemple, man ls affiche la documen-tation de la commande ls. De nombreux programmes offrent également une aide inté-grée à laquelle on accède à l’aide d’un argument, comme -h ou --help. Certains programmes, en particulier sur d’autres systèmes d’exploitation, affichent une aide lors-que vous ne passez aucun argument. C’est également le cas de lors-quellors-ques commandes Unix, mais elles sont rares. La raison provient de l’utilisation des commandes Unix dans les tubes. Nous y reviendrons plus loin. Mais, que pouvez-vous faire si vous ne connais-sez pas ou si vous avez oublié le nom de la commande dont vous avez besoin ?
apropos recherche dans les intitulés et les descriptions des pages de manuel les
expres-sions régulières passées en argument. Elle s’avère incroyablement utile lorsque vous avez oublié le nom d’une commande. Elle équivaut à man -k.
$ apropos music
cms (4) - Creative Music System device driver $ man -k music
cms (4) - Creative Music System device driver
locate et slocate consultent les bases de données du système (généralement compilées et
actualisées par une tâche cron) pour trouver, quasi instantanément, des fichiers ou des commandes. L’emplacement des bases de données, les informations indexées et la fré-quence des mises à jour peuvent varier d’un système à l’autre. Pour plus de détails, con-sultez les pages de manuel de votre système. Outre les noms de fichiers et les chemins,
slocate stocke des informations d’autorisation afin de ne pas présenter à l’utilisateur des
programmes auxquels il n’a pas accès. Sur la plupart des systèmes Linux, locate est un lien symbolique vers slocate. Sur d’autres systèmes, ces programmes peuvent être dis-tincts ou slocate peut ne pas exister.
$ locate apropos /usr/biSOpropos /usr/share/man/de/man1/apropos.1.gz /usr/share/man/es/man1/apropos.1.gz /usr/share/man/it/man1/apropos.1.gz /usr/share/man/ja/man1/apropos.1.gz /usr/share/man/man1/apropos.1.gz
Pour plus d’informations sur la commande find, consultez le chapitre 9.
Enfin, vous pouvez également essayer la commande ls. N’oubliez pas que si la comman-de recherchée se trouve dans votre répertoire comman-de travail, vous comman-devez la préfixer par ./ puisque, pour des raisons de sécurité, le répertoire courant ne se trouve généralement pas dans $PATH (voir les recettes 14.3, page 294, et 14.10, page 303).
Voir aussi
• help type ; • man which ; • man apropos ;
8 Chapitre 1 — Débuter avec bash
• man locate ; • man slocate ; • man find ; • man ls ;
• le chapitre 9, Rechercher des fichiers avec find, locate et slocate, page 191 ; • la recette 4.1, Lancer n’importe quel exécutable, page 71 ;
• la recette 14.10, Ajouter le répertoire de travail dans $PATH, page 303.
1.4. Obtenir des informations sur des fichiers
Problème
Vous avez besoin d’informations complémentaires sur un fichier, comme sa nature, son propriétaire, ses droits d’exécution, le nombre de liens physiques qu’il possède ou la date de dernier accès ou de dernière modification.
Solution
Utilisez les commandes ls, stat, file ou find. $ touch /tmp/fichier $ ls /tmp/fichier /tmp/fichier $ ls -l /tmp/fichier -rw-r--r-- 1 jp jp 0 2007-06-19 15:03 /tmp/fichier $ stat /tmp/fichier File: "/tmp/fichier"
Size: 0 Blocks: 0 IO Block: 4096 fichier régulier Device: 303h/771d Inode: 2310201 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 501/ jp) Gid: ( 501/ jp) Access: 2007-06-19 14:23:10.000000000 +0200 Modify: 2007-06-19 14:23:10.000000000 +0200 Change: 2007-06-19 14:23:10.000000000 +0200 $ file /tmp/fichier /tmp/fichier: empty $ file -b /tmp/fichier empty
1.4. Obtenir des informations sur des fichiers 9
$ echo '#!/bin/bash -' > /tmp/fichier
$ file /tmp/fichier
/tmp/fichier: Bourne-Again shell script text executable $ file -b /tmp/fichier
Bourne-Again shell script text executable Le chapitre 9 reviendra en détail sur la commande find.
Discussion
La commande ls affiche uniquement les noms de fichiers, tandis que ls -l fournit des détails supplémentaires sur chaque fichier. ls accepte de nombreuses options ; consultez sa page de manuel sur votre système pour les connaître. Voici quelques-unes des options intéressantes :
-a
Ne pas masquer les fichiers commençant par . (point).
-F
Afficher le type du fichier en ajoutant l’un des symboles de type suivant : /*@%=|.
-l
Présenter une liste détaillée.
-L
Révéler les informations sur le fichier lié et non sur le lien symbolique lui-même.
-Q
Encadrer les noms de fichiers avec des guillemets (extension GNU, non reconnue par tous les systèmes).
-r
Inverser l’ordre de tri.
-R
Parcourir les sous-répertoires.
-S
Trier d’après la taille de fichier.
-1
Utiliser le format court, mais avec un fichier par ligne.
Avec l’option -F, une barre oblique (/) désigne un répertoire, un astérisque (*) indique que le fichier est exécutable, un symbole arobase (@) désigne un lien symbolique, un si-gne égal (=) désisi-gne une socket et un tube (|) les FIFO (first-in, first-out).
stat, file et find acceptent de nombreux paramètres qui règlent le format de la sortie ;
consultez les pages de manuel de votre système pour les connaître. Par exemple, les op-tions suivantes produisent une sortie similaire à celle de ls -l :
10 Chapitre 1 — Débuter avec bash
$ ls -l /tmp/fichier
-rw-r--r-- 1 jp jp 0 2007-06-19 15:03 /tmp/fichier $ stat -c'%A %h %U %G %s %y %n' /tmp/fichier
-rw-r--r-- 1 jp jp 14 2007-06-19 14:26:32.000000000 +0200 /tmp/fichier $ find /tmp/ -name fichier -printf '%m %n %u %g %t %p'
644 1 jp jp Tue Jun 19 14:26:32 2007 /tmp/fichier
Ces outils ne sont pas disponibles sur tous les systèmes d’exploitation, ni dans certaines versions. Par exemple, la commande stat n’existe pas, par défaut, sur Solaris.
Vous devez savoir que les répertoires ne sont rien d’autres que des fichiers traités de ma-nière particulière par le système d’exploitation. Les commandes précédentes fonction-nent donc également sur les répertoires, même si vous devez parfois les modifier pour obtenir ce que vous souhaitez. Par exemple, utilisez ls -d pour afficher les informations concernant un répertoire, à la place de ls seule qui affiche le contenu d’un répertoire.
Voir aussi
• man ls ; • man stat ; • man file ; • man find ;
• le chapitre 9, Rechercher des fichiers avec find, locate et slocate, page 191.
1.5. Afficher tous les fichiers cachés
Problème
Vous voulez voir uniquement les fichiers cachés (avec un point) d’un répertoire afin de modifier un fichier dont vous avez oublié le nom ou pour supprimer des fichiers obso-lètes. ls -a affiche tous les fichiers, y compris ceux normalement cachés, mais elle est trop prolixe et ls -a .* ne vous convient pas.
Solution
Utilisez ls -d combinée à vos autres critères. ls -d .*
ls -d .b* ls -d .[!.]*
Vous pouvez également adapter la commande de manière à retirer . et .. de la liste. $ grep -l 'PATH' ~/.[!.]*
/home/jp/.bash_history /home/jp/.bash_profile
1.5. Afficher tous les fichiers cachés 11
Discussion
En raison de la manière dont le shell traite les caractères génériques, la combinaison .* ne se comporte pas forcément comme vous le supposez. L’expansion des noms de fichiers, ou globalisation (globbing), considère toute chaîne contenant les caractères *, ? ou [ com-me un motif et la remplace par une liste alphabétique des noms de fichiers qui corres-pondent à ce motif. * correspond à n’importe quelle chaîne, y compris la chaîne vide, tandis que ? équivaut à un seul caractère. Les caractères placés entre [ et ] définissent une liste ou une plage de caractères, chacun devant correspondre. Il existe également d’autres opérateurs de correspondance de motifs, mais nous ne les présenterons pas dans ce chapitre (voir les sections Caractères pour la correspondance de motifs, page 546, et
Opérateurs pour la correspondance de motifs étendue extglob, page 547). Ainsi, *.txt
signi-fie tout fichier se terminant par .txt, tandis que *txt représente tout fichier se terminant par txt (sans point). f?o correspond à foo ou à fao, mais pas à fooo. Vous pourriez donc penser que .* correspond à tout fichier qui commence par un point.
Malheureusement, l’expansion de .* inclut . et .., qui sont donc tous deux affichés. Au lieu d’obtenir uniquement les fichiers commençant par un point dans le répertoire de travail, vous obtenez également ces fichiers, tous les fichiers et répertoires du répertoire courant (.), tous les fichiers et répertoires du répertoire parent (..), ainsi que les noms et le contenu de tous les sous-répertoires du répertoire de travail qui commencent par un point. C’est, pour le moins, assez perturbant.
Vous pouvez essayer la même commande ls avec et sans l’option -d, puis echo .*. Cette commande echo affiche simplement le résultat de l’expansion de .* par le shell. Essayez également echo .[!.]*.
.[!.]* est un motif dans lequel [ ] précise la liste des caractères employés dans la cor-respondance, mais le symbole ! du début inverse le rôle de la liste. Nous recherchons donc tout ce qui commence par un point, suivi de tout caractère autre qu’un point, suivi d’un nombre quelconque de caractères. Vous pouvez également employer ^ pour inver-ser une classe de caractères, mais ! fait partie des spécifications de POSIX et est donc plus portable.
.[!.]* ne trouvera pas un fichier nommé ..toto. Vous pouvez ajouter quelque chose comme .??* pour trouver les correspondances avec tout ce qui commence par un point et qui contient au moins trois caractè-res. Mais, ls -d .[!.]* .??* affiche alors deux fois tout ce qui corres-pond aux deux motifs. Vous pouvez également utiliser .??* seul, mais les fichiers comme .a sont alors oubliés. La solution dépend de vos besoins et de votre environnement. Il n’existe pas de réponse adaptée à tous les cas.
$ ls -a
. ..toto .fichier_point_normal .. .a fichier_normal
$ ls -d .[!.]*
