Le shell sans peine : techniques avancées

De Wiki de la communauté Mandriva.


Cet article fait suite à la première partie : Le shell sans peine. Vous trouverez des techniques supplémentaires pour gagner en efficacité.


Sommaire

Enchaînement de commandes

Vous vous rendrez compte peu à peu que certaines combinaisons de commandes sont particulièrement fréquentes. Vous pourriez alors avoir envie de lancer toutes ces commandes sur une seule ligne et de penser à autre chose. Pas de problème. Le shell vous permet de placer à cet effet divers symboles spéciaux entre les commandes. Cette sous-section présente les deux plus importants. Vous pourrez remarquer, dans ce qui suit, que je place des espaces autour de ces symboles par souci de lisibilité. Ils ne sont cependant pas nécessaires en pratique : il n'y a aucune différence par exemple entre ls -a ; du -hs et ls -a;du -hs.

Le point-virgule

commande1 ; commande2

exécute commande1 d'abord, puis commande2, même si commande1 a renvoyé un code d'erreur. Exemple :

ls -a ; du -hs

affichera d'abord à l'écran une liste complète du contenu du répertoire courant et ensuite l'espace total occupé par les fichiers de ce répertoire et de ses sous-répertoires.

Le &&

commande1 && commande2

exécute commande2 si et seulement si commande1 s'est achevée sans erreur. Exemple :

ls -a dirbidon && du -hs

renverra

ls: dirbidon: No such file or directory

et du ne sera absolument pas exécuté (en supposant bien sûr que vous n'avez pas sur votre disque de répertoire dirbidon ;-)). Si vous aviez utilisé ; au lieu de &&, la commande du aurait été exécutée.


L'exemple classique qui sert à mettre en évidence la différence entre ; et &&, et l'utilité de l'enchaînement de commandes est la compilation et l'installation du noyau de Linux. Pour compiler et installer le noyau de Linux, on doit exécuter un ensemble de commandes les unes après les autres : make dep, make clean, make bzImage, make modules, make modules_install et make install. Il serait bien ennuyeux de lancer une de ces commandes, puis d'attendre que son exécution s'achève, lancer la commande suivante, attendre à nouveau, lancer la suivante etc. D'un autre côté chacune des commandes de cette série ne marchera correctement que si toutes les commandes précédentes ont été exécutées sans erreur. Or si vous avez recours au symbole ; pour enchaîner ces commandes alors si l'une d'entre elles échoue, le reste des commandes sera quand même exécuté, et vous pourriez vous retrouver avec une image du noyau défectueuse dans le répertoire /boot. Vous devez donc utiliser && :

make dep && make clean && make bzImage && make modules && make modules_install && make install

Cette ligne de commande compilera le noyau et ses modules et les installera sans requérir une quelconque interaction avec vous.

Exécuter une commande en tâche de fond (à l'arrière-plan)

Lancer une commande en tâche de fond

Lorsque vous lancez une commande ou un programme sur un terminal celui-ci reste bloqué tant que cette commande, ou ce programme, est en cours d'exécution. Sous Unix, on dit alors que la commande ou le programme s'exécutent « au premier plan ». Si vous avez alors besoin de lancer une autre commande vous devez ouvrir un autre terminal.

Mais il y une façon plus élégante de s'en sortir : la mise « à l'arrière-plan » (on peut dire aussi : l'exécution en tâche de fond) de la tâche courante (souvent appelée alors un « job »). Lorsque vous mettez une commande (un « job ») à l'arrière-plan, elle abandonne immédiatement le terminal, si bien que celui-ci est tout de suite disponible et que vous pouvez y entrer autre chose. Pour cela tout ce que vous avez à faire est de placer un & après la commande. Par exemple, comme ceci :

unison &

cette commande dit au shell d'exécuter le logiciel de synchronisation et de sauvegarde Unison « à l'arrière-plan » (autrement dit de l'exécuter en tant que « job »).


La commande jobs vous indique quelles commandes et quels programmes sont en train de s'exécuter en tant que jobs sur cette fenêtre de terminal :

jobs
[1]+ Running unison &

Comment tuer une commande qui s'exécute en tâche de fond

Ceci n'est pas sans importance lorsque vous envisagez de fermer une fenêtre de terminal car, en fermant un terminal, tous les jobs en cours d'exécution qui ont été lancés depuis ce terminal sont interrompus, autrement dit, si vous fermez ce terminal-ci, le programme Unison, qui a été lancé depuis ce terminal, sera arrêté lui aussi.

Attention donc, à l'occasion d'un « nettoyage » de votre interface graphique, à ne pas, d'un clic frénétique et hâtif, fermer la console qui abrite le programme qui tourne en tâche de fond depuis un bon moment en accumulant de précieuses données : les données seraient perdues et tout serait à recommencer...

D'un autre côté, vous pourriez vous dire que fermer le terminal, ou, ce qui revient souvent au même, clore la session du shell par un rapide <Ctrl d>, est un excellent moyen d'arrêter une bonne fois l'ensemble des programmes ouverts à l'arrière-plan. A vrai dire, il est plutôt conseillé de laisser de tels programmes se terminer d'eux-mêmes, d'une mort naturelle, ou s'ils ont ouvert une fenêtre, d'utiliser les outils (boutons...) qui y sont offerts pour fermer le programme de façon « normale ». Toutefois, si aucune fenêtre ne le permet et si vous vous apercevez qu'un programme à l'arrière-plan vous est finalement inutile et consomme des ressources pour rien ou semble carrément planter, vous pouvez l'arrêter « proprement » de façon très simple, en donnant comme argument à la commande kill son « numéro de job », précédé du signe de pourcentage (%) :

kill %numero_de_job

Ainsi, dans notre exemple,

kill %1

terminera proprement Unison.

Si le programme est planté au point de ne pas « mourir » à la suite de cette dernière commande, alors et alors seulement, vous devrez utiliser la commande kill avec le « signal de mort » 9 (signal SIGKILL) et le PID du processus concerné (que vous obtiendrez par la commande top ou ps -aux) :

kill -s 9 PID

Comment faire passer une commande de l'avant-plan à l'arrière-plan

Et maintenant, que faire si vous souhaitez placer à l'arrière-plan un programme qui est en cours d'exécution à l'avant-plan ? Rien de plus facile :

unison
<CTRL z>
[2]+ Stopped unison
bg
[2]+ unison &

La combinaison de touches <CTRL z> suspend l'exécution de tout programme qui tourne à l'avant-plan sur le terminal, ceci fait, vous pouvez ensuite réactiver le programme suspendu de telle sorte qu'il s'exécute maintenant en toile de fond : il vous suffira pour obtenir ce résultat de lancer la commande bg (la commande fg réactiverait au contraire le programme en le mettant à l'avant-plan).

Notez que, dans certains cas, il peut être utile de faire démarrer une application graphique à l'avant-plan à partir d'un terminal : si vous procédez ainsi, en effet, tous les messages d'erreur éventuels que l'application générera seront affichés sur le terminal et même s'ils ne vous sont pas utiles à vous ils pourront l'être pour la personne que vous appelerez à l'aide si quelque chose ne tourne pas rond !

Certains programmes graphiques cependant, en général pendant leur phase d'essais ou de bêta tests, continuent à envoyer leurs messages vers le terminal qui les contrôle même s'ils ont été placés à arrière-plan. Si ce comportement vous gêne vous pouvez l'éviter en tapant :

commande &>/dev/null &

ce qui a pour effet non seulement de mettre le programme à l'arrière-plan mais aussi d'envoyer toutes les sorties vers le fichier spécial /dev/null. /dev/null est le broyeur de documents du système, tout ce que vous y expédiez disparaît immédiatement sans laisser de trace.

Substitution de commande

La substitution de commande est une fonctionnalité très pratique. Supposons que vous souhaitiez jeter un coup d'oeil au fichier DIR_COLORS qui gère l'usage des couleurs affichées en console par la commande ls, mais que vous ne sachiez pas où il se trouve. Comme vous êtes un utilisateur averti, vous avez déjà entendu parler de la commande locate et le package slocate est installé sur votre machine. Vous faites donc un :

locate DIR_COLORS

et vous découvrez que ce fichier se trouve dans /etc/DIR_COLORS. Parvenu à ce point, vous pouvez soit utiliser le visionneur de pages de terminal less soit votre éditeur de fichier habituel pour afficher le fichier en question, en donnant ce chemin comme argument. La substitution de commande facilite grandement tout cela :

less $(locate DIR_COLORS)

permet de réaliser toutes ces opérations en une seule étape. La sortie de la commande locate DIR_COLORS (= /etc/DIR_COLORS) est prise comme argument par le visionneur less, qui affiche alors le fichier.

La syntaxe de ce mécanisme est la suivante :

commande1 $(commande2)


Au lieu de $(), on peut utiliser de simples « accents graves » ou « guillemets simples inversés » (anglais backquotes) :

commande1   `commande2`

C'est économique en termes de frappe mais plus difficile à lire dans un script et plus facile à confondre avec l'emploi « normal » des guillemets simples, que le shell n'accepterait pas comme des indicateurs de substitution de commande. Je préfère pour ma part la première méthode, mais à vous de voir.

Voici un autre exemple. Supposons que vous souhaitiez tuer un stupide programme machin. Vous pouvez le faire en commençant par détecter son (futur lien) identificateur de processus - (PID) à l'aide de la commande pidof puis en lançant la commande kill avec ce PID comme argument. Au lieu de taper :

pidof machin
567
kill 567

tapez plutôt :

kill `pidof machin`

Plus compact, non ? (noter que la commande pidof n'est accessible que sous root).

Dans les sections suivantes, je vais aborder deux autres mécanismes utiles du shell, l'expansion des noms de fichier et la redirection des sorties.

L'expansion des noms de fichier

L'expansion des noms de fichier permet de fournir une multiplicité de noms de fichier à une commande sans avoir à les écrire tous en entier. On utilise pour cela des caractères spéciaux, appelés « jokers » ou « méta-caractères ».

Le joker *

Si vous voulez par exemple effacer avec la commande rm tous les fichiers d'un répertoire dont les noms se terminent par la chaîne de caractères .bak, alors, au lieu de taper chaque nom de fichier en position d'argument de rm, on utilise le joker * :

rm *.bak

le caractère * correspond à zéro, un ou plusieurs caractères. Dans cet exemple vous dites donc au shell que l'argument de la commande rm est élargi à « tous les fichiers dont les noms se terminent par (ou dont le nom se réduit à) .bak », le shell opère ainsi et passe cet argument élargi à la commande rm.

Comme nous le verrons, il est important de bien comprendre que le shell lit et interprète la ligne de commande avant que la commande elle-même ne le fasse. Ceci présente l'avantage de permettre l'utilisation de jokers avec (presque) toutes celles des commandes du shell qui prennent comme arguments des chaînes de caractères (noms de fichiers, noms de répertoires, motifs faisant l'objet d'une recherche etc.).

Jouons encore un peu avec le joker *. Vous avez par exemple un répertoire qui contient les fichiers 124.bak, 346.bak et 583.bak. Vous voulez faire le ménage et conserver uniquement 583.bak. Vous faites alors simplement ceci :

rm *4*.bak

Le shell élargit l'argument de rm à « tous les noms de fichiers qui contiennent le nombre 4 et qui se terminent par la chaîne de caractères .bak ». Notez que

rm 4*.bak

n'aurait pas marché, puisque cela n'aurait englobé que les noms de fichier qui commencent par le nombre 4. Comme il n'y a pas de fichier de ce genre dans le répertoire, le shell aurait élargi ce type d'argument à… une chaîne nulle et rm aurait renvoyé un message d'erreur :

rm: ne peut évaluer par lstatt() `4*.bak': Aucun fichier ou répertoire de ce type

Si vous voulez garder le fichier 346.bak mais effacer 124.bak et 583.bak, c'est un peu plus délicat car les fichiers à effacer n'ont rien en commun à part la dernière partie de leur nom. Mais, chanceux comme vous l'êtes, vous pouvez aussi définir des fichiers par ce qu'ils ne possèdent pas !

rm *[!6].bak

Cette ligne se lit ainsi : « effacer tous les fichiers qui se terminent par la chaîne de caractères .bak sauf ceux qui se terminent par la chaîne 6.bak ». Il faut mettre entre crochets le signe de négation ! et le caractère sur lequel il porte (ici 6), sinon le shell interprèterait le point d'exclamation comme le début d'une substitution de commande de l'historique des commandes. La négation fonctionne avec tous les types d'expansion de nom de fichier introduits dans cet article. (Note : La commande history affiche une liste numérotée de commandes précédemment appelées, si n est le numéro d'une de ces commandes, alors !n permet de l'exécuter. C'est cela que les crochets permettent d'éviter dans l'exemple qui précède.)

Notez qu'il est très facile de se tirer une balle dans le pied en utilisant le joker * et la négation. Devinez par exemple ce que fait la ligne :

rm *[!6]*.bak

Elle efface tous les fichiers du répertoire dont le nom se termine par .bak, y compris ceux dont le nom contient un 6 ! Si vous placez le joker * après et avant une négation, il rend la négation quasi inutile : ici le shell élargit l'argument de rm à « tous les noms de fichier qui possèdent un caractère différent de 6 dans une position quelconque avant .bak ». Dans notre exemple, parmi les fichiers qui se terminent par .bak seuls seraient épargnés des fichiers dont le nom comporterait uniquement une suite de 6 suivie de .bak, comme 666.bak.

Le joker ?

Le second joker est le point d'interrogation : ?.
Pour l'expansion de noms de fichier, le point d'interrogation représente un caractère et un seul.

Pour mettre cela en évidence ajoutons deux nouveaux noms de fichiers à ceux que nous avions déjà, 311.ARCH et un.text. Maintenant, affichons la liste de tous les fichiers qui possèdent exactement quatre caractères après le point :

ls *.????

fera exactement cela et fera apparaître dans la liste affichée en sortie nos deux nouveaux fichiers.

Le joker point d'interrogation est aussi un moyen utile d'éviter le « piège de la négation » mentionné à la fin de la section #Le joker *. Ainsi, la ligne de commande :

rm *[!4]?.*

doit être comprise comme : «  effacer tous les fichiers dont le nom contient au moins deux caractères avant le point sauf ceux qui possèdent un 4 dans l'avant-dernière position avant le point » et elle efface donc, dans le répertoire qui nous sert d'exemple, tous les fichiers (124.bak, 583.bak, 311.ARCH et un.text), à la seule exception de 346.bak.

Tester la présence d'une gamme de caractères

Autre chose encore ? Mais oui. Nous avons vu jusqu'ici des cas d'expansion de nom de fichier dans lesquels pour une certaine position on testait la présence d'un seul caractère. Mais rien n'empêche de tester plus d'un caractère dans une même position :

ls [13]*

affiche la liste de tous les fichiers qui commencent par le caractère 1 ou par le caractère 3; dans notre exemple les fichiers 124.bak, 311.ARCH et 346.bak correspondent. Notez que vous devez mettre les caractères concernés entre crochets, sinon ce seraient les fichiers qui commencent par 13 qui seraient sélectionnés.

Il ne manque plus à notre bonheur que la possibilité de définir des expansions pour des gammes entières de caractères.

ls *[3-8]?.*

affiche la liste de tous les fichiers dont l'avant-dernier caractère avant le point est un nombre entre 3 inclus et 8 inclus. Dans notre exemple cela correspond aux fichiers 346.bak et 583.bak.

Enfin, il est aussi possible, grâce aux crochets, d'exiger la présence d'un caractère qui n'appartienne pas à une certaine gamme de caractères. Il suffit pour cela de faire précéder la liste des caractères entre crochets par le signe de négation ! dont il a déjà été question dans cette page (à la place de !, le signe ^ serait aussi possible aussi, du reste). Ainsi :

ls *[!4-8]?.bak

afficherait la liste des fichiers dont le nom se termine par .bak précédé d'un caractère quelconque (?), lui-même précédé d'un caractère qui ne doit pas être l'un des chiffres allant de 4 à 8. 346.bak et 586.bak ne seraient donc pas affichés mais 124.bak le serait.

Expansion des noms de fichiers et caractères spéciaux

Ces puissants mécanismes d'expansion ont un inconvénient : le shell tentera toujours de les mettre en œuvre et il le fera avant que la commande n'interprète ses arguments. Il peut alors arriver que ces mécanismes se mettent en travers de votre chemin.

Supposez que vous ayez aussi, dans le répertoire qui nous a servi d'exemple dans les sections précédentes, un fichier dénommé !56.bak. Essayez de faire en sorte qu'il soit sélectionné par l'expansion de noms de fichiers :

rm !*
rm
rm: opérande manquante

Le shell interprète !* comme une substitution d'une commande invoquant l'historique (signifiant : « insérer tous les arguments de la commande précédente »), et non comme un indicateur d'expansion de fichier. (Tant que vous y êtes, notez donc aussi que !$ aurait signifié « insérer le dernier argument de la commande précédente ». Deux abréviations bien utiles, à retenir. Sur tout ceci voir L'historique du shell).

Un certain nombre d'outils de la ligne de commande sous Linux, tels que (e)grep, sed, awk, find et locate doivent traiter eux-mêmes les expansions de nom de fichiers.

Afin que seule la commande puisse les interpréter, et non le shell, on doit les mettre entre guillemets :

find . -name *[A-Z]*  -print
find: les chemins doivent précéder l'expression

Ici la commande find devrait rechercher tous les fichiers qui contiennent (au moins) une lettre majuscule, mais elle ne renvoie en fait qu'un message d'erreur ! La version appropriée, avec l'expression suivant -name entre guillemets, sera :

find . -name '*[A-Z]*'  -print
./311.ARCH

Vous pouvez aussi protéger des caractères spéciaux tels que !, $, ? ou une espace vide à l'aide d'une barre oblique inverse (anglais backslash) :

ls \!*
!56.bak

ou avec des guillemets (simples) :

ls '!'*
!56.bak

Noter que la question de savoir où placer les guillemets peut alors se poser.

ls '!*'

chercherait un fichier nommé '!*' puisque le second joker serait alors entre guillemets lui aussi, et de ce fait interprété littéralement.

Les méta-caractères et les fichiers cachés

Par défaut, les jokers ne « voient » pas le point initial des noms de fichiers ou de répertoires « cachés ». Sur tout cela, voir cette section.

La redirection des sorties

C'est la philosophie d'Unix que de développer beaucoup de petits programmes qui excellent chacun dans une tâche particulière. Les tâches complexes ne sont pas accomplies par des programmes complexes mais plutôt en attachant bout à bout des programmes les uns aux autres à l'aide d'un petit nombre de mécanismes du shell. L'un d'eux est la redirection de sorties.

Redirection entre commandes

On fait cela à l'aide de « tubes » (anglais pipe), représentés par le symbole |. La syntaxe est la suivante :

commande1 | commande2 | commande3 etc

Vous en avez sûrement déjà rencontré. Ils sont fréquemment utilisés pour rediriger la sortie d'un programme vers un visionneur de page comme more ou less, comme dans :

ls -l | less

La première commande envoie une liste du contenu du répertoire de travail et la seconde l'affiche et permet de la faire défiler commodément. Voici un exemple plus complexe :

rpm -qa | grep ^x | less

La première commande envoie une liste de tous les RPM installés, la seconde ne retient (grâce au « filtre » grep) que ceux qui commencent par un x (^x) et la troisième affiche le résultat sous forme d'une liste qu'on peut faire défiler page par page (attention, pour voir apparaître l'affichage en console, il peut être nécessaire de patienter un peu, le traitement de la liste des rpm étant assez long).

Redirection vers un fichier ou en provenance d'un fichier

On peut vouloir sauvegarder la sortie d'une commande dans un fichier ou au contraire fournir à une commande un argument en provenance d'un fichier.
C'est ce que font les opérateurs de redirection > et <.
Une ligne de commande de la forme :

commande > fichier

sauvegarde la sortie de commande dans fichier en écrasant la totalité du contenu précédent de fichier. Par exemple :

ls > liste_du_rep

sauvegarde la liste du contenu du répertoire courant dans un fichier appelé liste_du_rep.
Une ligne de commande de la forme :

commande < fichier

utilise fichier comme entrée de commande.
Il est possible d'utiliser les deux opérateurs dans un même ligne, par exemple comme ceci :

sort < liste_du_rep > liste_du_rep_triee

envoie le contenu de liste_du_rep à la commande sort, qui le trie et place le contenu trié obtenu en sortie dans le fichier liste_du_rep_triee. Mais, bien sûr, si vous êtes malin, vous ferez tout cela en une seule étape, à l'aide d'un tube :

ls | sort > liste_du_rep_triee

Voilà maintenant un cas particulier de redirection :

commande 2> fichier

Ceci place uniquement les messages d'erreur de commande dans fichier. Cela peut se révéler utile de temps en temps...

Un autre opérateur est >>. Celui-ci ajoute la sortie au contenu d'un fichier préexistant :

echo "chaîne" >> fichier

ajoute chaîne au contenu du fichier fichier. Voilà donc une façon d'éditer rapidement un fichier sans ouvrir un éditeur de texte !

Il y a cependant une contrainte importante qui pèse sur les opérateurs < et > : Quelque chose comme :

commande < fichier1 > fichier1

effacera le contenu de fichier1. Toutefois

commande < fichier1 >> fichier1

marchera et ajoutera le contenu traité de fichier1 au même fichier.

Cela fait pas mal de choses, tout ça, non ? ;-) Pas de quoi paniquer, vous pouvez tout apprendre pas à pas à votre rythme. La pratique conduit à la perfection... Une fois que vous serez familiarisés avec les mécanismes du shell les plus courants, vous pourrez éprouver le besoin de personnaliser votre environnement. Vous trouverez quelques suggestions dans les deux prochaines sections. Dans la dernière section vous trouverez une petite FAQ qui traite des messages d'erreur les plus courants du shell et de certains paramétrages mineurs de la configuration.

Les fichiers de configuration du shell Bash

Lorsque vous faites, dans votre répertoire personnel,

ls .bash*

toute une liste de fichiers s'affiche :

- .bash_history contient une liste des commandes que vous avez lancées

- .bash_logout contient une liste de commandes qui sont exécutées lorsque vous quittez le shell

- .bash_profile contient une liste de commandes qui sont exécutées lorsque vous vous identifiez

- .bashrc contient une liste de commandes qui s'exécutent chaque fois que vous ouvrez un nouveau shell.


Notez bien la différence suivante entre les deux derniers fichiers : .bash_profile est lu une seule fois en début de session, alors que .bashrc est lu chaque fois que vous ouvrez un nouveau terminal (autrement dit une nouvelle fenêtre xterm). Traditionnellement, lors d'une installation, vous êtes censé définir des variables telles que PATH dans .bash_profile, et des éléments tels que des alias ou des fonctions dans .bashrc.

Tous les fichiers dont nous venons de parler définissent des paramétrages pour un utilisateur particulier. Les paramétrages pour l'ensemble du système sont stockés dans :

  • /etc/profile
  • /etc/bashrc

et dans les fichiers du répertoire :

  • /etc/profile.d

Vous devriez cependant opter autant que possible pour une configuration des fichiers utilisateur : éditer ces fichiers ne vous oblige pas à passer en root et ils vous permettent de définir des paramétrages différents pour root et pour chaque compte utilisateur, ce qui peut être une bonne chose. En cas de conflit entre les paramétrages utilisateur et les paramétrages système ce sont les paramétrages utilisateur qui l'emportent.

Pour plus d'informations sur tout cela voir la page sur Les fichiers de configuration du shell.

Maîtriser l'invite de la ligne de commande

L'invite est la première chose que vous voyez lorsque vous ouvrez une console (un xterm). Elle ressemble à ceci :

[compte@nomdhote ~]$

Par défaut, elle affiche votre nom d'utilisateur suivi de l'arobase (@) puis le nom d'hôte de votre machine (qui par défaut sera localhost) et le nom du répertoire de travail courant (le tilde (~ ) est le raccourci Unix pour le répertoire personnel).

Traditionnellement, le dernier caractère de l'invite indique si vous êtes connecté comme simple utilisateur ($) ou comme root, auquel cas il est remplacé par un dièse (#).

Vous pouvez définir ou modifier votre invite en changeant le contenu de la variable $PS1. La commande :

echo $PS1

affiche la valeur courante de cette variable. Vous trouverez les caractères spéciaux qui s'affichent alors, avec leur signification, dans man bash, à la section SYMBOLE D'ACCUEIL. Note : Pour faire une recherche dans bash, une fois le fichier ouvert, tapez une barre oblique /, puis le ou les mots que vous souhaitez trouver. Pour plus de détails voir (futur lien) Prise en main de man.

Besoin d'une suggestion de ce que pourrait être une meilleure invite ? Eh bien, tout d'abord, l'invite par défaut n'est pas très adaptée aux utilisateurs oublieux, car elle montre seulement la dernière partie de votre chemin courant. Si vous voyez une invite comme :

[julie@paradis bin]$

votre répertoire de travail courant pourrait être /bin, /usr/bin, /usr/local/bin ou /usr/X11R6/bin. Evidemment, vous pouvez toujours taper :

pwd

(anglais « print working directory » = « afficher le répertoire de travail »)

pour découvrir où vous vous trouvez mais n'y aurait-il pas un moyen de dire au shell d'indiquer cela de lui-même ?

Mais si, il y en a bel et bien un ! L'aspect de l'invite - et une grande part des autres paramètrages que nous évoquons ici - est fixé dans /etc/bashrc. Vous pouvez modifier ce fichier en l'éditant sous root dans un éditeur de texte. Vous pouvez aussi changer l'invite pour un unique utilisateur particulier en éditant .bash_profile ou .bashrc dans le répertoire personnel de cet utilisateur, voir (#Les fichiers de configuration du shell Bash).

Les paramètres qui permettent de modifier l'invite sont décrits dans man bash, section SYMBOLE D'ACCUEIL. Vous pouvez ajouter des petites choses très chouettes comme l'heure qu'il est, sous différents formats, ou le numéro d'historique de la commande et même diverses couleurs d'affichage.

Mon paramétrage favori, celui qui figure dans mon fichier utilisateur .bashrc est :

PS1="\[\033[1m\][\w]\[\033[0m\] "

le .bashrc du compte root contient :

PS1="\[\033[0;31m\][\w]\[\033[0m\] "

et j'obtiens une invite telle que :

[/usr/bin]

où seul le chemin (complet) du répertoire courant apparaît. J'ai éliminé le nom d'utilisateur et le nom de machine, qui ne me sont d'aucune utilité. Mais je veux pouvoir me rendre compte au premier coup d'oeil si je suis connecté à la console comme utilisateur ou comme root : avec ces paramétrages l'invite utilisateur sera noire sur fond clair ou blanche sur fond sombre tandis que l'invite de root sera toujours rouge.

Ce qui donne donc :
Utilisateur :

Image:invite_user.png

Superutilisateur (root) :

Image:invite_root.png

Pour mieux comprendre...

Pour obtenir des informations claires et précises sur le codage des couleurs tel qu'il est utilisé dans les exemples qui précèdent et dans celui qui suit, on pourra consulter Le shell en couleur : du bon usage des codes couleur ANSI.

Un paramétrage plus modeste pourrait être :

PS1="\u: \w\\$ "

qui aboutirait à des invites de ce type :

nom_d_utilisateur: /$

Par exemple :

Image:invite_modeste.png

mais qui veut vraiment rester modeste ? :-)

Vous pouvez essayer divers paramétrages à la volée en utilisant la commande export, par exemple

export PS1="\u: \w\\$ "

Si vous avez trouvé une invite qui vous va, mettez-la donc à la fin de votre ~/.bashrc ou, si vous voulez qu'elle vaille pour tous les utilisateurs du système, à la fin du fichier /etc/bashrc. Elle sera activée automatiquement sur chaque console (sur chaque terminal) que vous ouvrirez.

Vous pouvez même « thématiser » votre invite, autrement dit utiliser différentes couleurs ou la faire ressembler à une bonne vieille invite de C64...

Pour essayer... :

Pour essayer chacune des invites que nous venons de mentionner, vous pouvez :

- sélectionner dans la présente fenêtre la ligne $PS1 = ... qui lui correspond,
- la copier (Ctrl+C),
- vous rendre dans l'utilitaire Konsole de KDE,
- coller le contenu du presse-papier dans la ligne de commande (Menu Edition -> Coller).

Le résultat apparaîtra immédiatement...

Modifier la variable $PATH

$PATH, comme $PS1, appartient au groupe des variables d'environnement. Tapez :

set

pour obtenir une liste de toutes les variables d'environnement définies dans votre environnement courant.

Les variables d'environnement que vous voyez là sont définies dans les fichiers de configuration du shell, soit par l'utilisateur dans son propre ensemble de fichiers de configuration du shell ou, pour l'ensemble du système, par root, via les fichiers de configuration de /etc. Si vous êtes dans un environnement de type X, quelques autres variables sont activées par les fichiers de démarrage de X et par votre gestionnaire de fenêtre ou votre environnement de bureau.

Vous ne devez pas vous mêler du paramétrage de la plupart de ces variables, à moins de savoir exactement ce que vous faites et pourquoi. Il peut être utile cependant de savoir modifier la variable $PATH, car elle détermine les noms des répertoires où le shell recherche les commandes et les programmes, autrement dit l'ensemble des fichiers exécutables. Si la commande que vous voulez lancer est dans un répertoire qui est énuméré dans $PATH, vous n'avez pas à taper le chemin complet de cette commande, mais seulement son nom. Certains logiciels tiers (NdTrad de l'anglais : « third-party software » = logiciel dont l'auteur n'est ni l'utilisateur ni l'auteur de la distribution Linux (pour nous Mandriva)) n'installent pas leurs fichiers exécutables dans les répertoires standards destinés par Linux aux commandes et aux programmes. Ajouter leur lieu d'installation non-standard dans le $PATH est alors une tâche qu'il peut être bon d'apprendre à mener à bien. De plus, cela vous apprendra aussi, plus généralement, à traiter les variables d'environnement.

Tout d'abord vous avez certainement remarqué que le nom des variables d'environnement sont en majuscules. Ce n'est qu'une convention, mais comme Linux distingue les majuscules des minuscules, il est important de garder cela en tête. Vous pouvez définir une variable $path ou $pAtH, mais le shell ne l'utilisera pas.

D'autre part les noms de variable sont parfois précédés par un '$' et parfois non. Pour assigner une valeur à une variable on utilise son nom sans le faire précéder de $ :

PATH=/usr/bin:/bin:/usr/local/bin:/usr/X11R6/bin

pour accéder au contenu d'une variable, on la fait précéder de '$' :

echo $PATH
/usr/bin:/bin:/usr/local/bin:/usr/X11R6/bin

sinon, le nom de la variable est traité comme une simple chaîne de caractères :

echo PATH
PATH

Un troisième point est tout particulièrement important en ce qui concerne la variable $PATH. On peut non seulement remplacer le contenu d'une variable, mais aussi ajouter simplement une nouvelle chaîne à sa valeur. La plupart du temps on ne souhaite pas faire quelque chose comme PATH=/un/repertoire parce que cela effacerait tous les autres répertoires de votre $PATH et cela vous forcerait à taper le nom complet du chemin pour chaque commande que vous exécutez sur ce terminal qui ne correspond pas à un programme de ce répertoire. Au lieu de cela vous devez simplement ajouter le nouveau répertoire ainsi :

PATH=$PATH:/un/repertoire

Ici PATH reçoit sa valeur courante (représentée par $PATH), augmentée d'un répertoire supplémentaire.

Jusqu'à présent vous disposez d'une variable $PATH pour le terminal dans lequel vous avez tapé la commande précédente. Si vous ouvrez un nouveau terminal et lancez la commande echo $PATH, vous verrez le vieux $PATH, sans le répertoire que vous venez d'ajouter. Vous avez défini une variable d'environnement locale (restreinte au terminal dans lequel vous l'avez défini).

Afin de définir une variable globale qui sera reconnue par tous les teminaux que vous ouvrirez au cours de la session en cours, il vous faudra exporter la variable locale avec la commande export :

export PATH=$PATH:/un/répertoire

Si maintenant vous ouvrez un nouveau terminal et y tapez :

echo $PATH

la nouvelle valeur de $PATH sera prise en compte dans ce terminal aussi. Notez cependant que la commande export initialise ou modifie des variables pour le terminal dans lequel elle est lancée et pour les terminaux qui sont lancés après cela. Les terminaux qui étaient déjà ouverts continueront à avoir la vieille version de $PATH.

Pour ajouter un répertoire de façon permanente à votre $PATH, vous n'avez qu'à ajouter la commande export ci-dessus à votre fichier de configuration du shell ~/.bash_profile.

Comme cela est expliqué dans la page avancée sur Les fichiers de configuration du shell, .bashrc est relancé chaque fois que vous ouvrez un nouveau shell, aussi si vous ajoutez un répertoire au PATH dans ce fichier, il sera ajouté à nouveau chaque fois que vous ouvrirez un terminal. Votre variable PATH ne cessera de croître par réduplication des entrées de répertoire. Pour éviter cela vous devez ajouter le nouveau chemin '/'truc/machin de votre PATH dans le fichier ~/.bash_profile.

Les dernières sections de cet article introduiront deux autres méthodes de configuration avancées et une FAQ qui traite de questions mineures concernant la configuration et certains messages d'erreur.

Alias et fonctions

Mémoriser toutes sortes de commandes, avec leurs options, et recommencer sans arrêt à les taper est quelque chose de vraiment empoisonnant. Heureusement, on peut, dans une certaine mesure, l'éviter. Il est possible en effet de définir des raccourcis pour les commandes fréquemment utilisées. Ces raccourcis peuvent soit être définis sous la forme relativement simple d'alias, soit prendre la forme et la syntaxe, un peu plus complexe, de fonctions du shell.

Les alias

Créer un alias

A titre d'exemple, j'ai longtemps utilisé cette commande pour envoyer mon travail à MUO (MandrakeUser.Org) :

rsync -e ssh -z -t -r -vv --progress /home/tom/web/muo/rsmuo/docs muo:/www/mandrakeuser/docs

Naturellement, ce serait épouvantable d'avoir à taper cette commande chaque fois. J'ai donc défini ce qu'on appelle un « alias » dans mon .bashrc d'utilisateur :

alias upmuo='rsync -e ssh -z -t -r -vv --progress /home/tom/web/muo/rsmuo/docs muo:/www/mandrivakeuser/docs'

Maintenant, tout ce que j'ai à faire pour envoyer mon travail consiste simplement à taper :

upmuo

Nettement plus rapide !!


Voici la syntaxe usuelle pour définir un alias :

alias raccourci='commande'

Les guillemets sont nécessaires lorsque la commande contient des espaces (notamment entre commande et option). Notez qu'on peut mettre des guillemets simples ou des guillemets doubles et si vous subodorez qu'il doit y avoir une différence entre les deux, vous n'avez pas tort… ;-). Les guillemets simples font perdre leur signification particulière à tous les caractères spéciaux, les guillemets doubles font perdre leur signification particulière à tous les caractères spéciaux sauf $ (l'indicateur de substitution de paramètre) et ` (l'indicateur de substitution de commande). Ce qui veut dire que pour avoir recours à la substitution de variable ou de commande dans les alias, vous devez utiliser des guillemets doubles. En me référant à l'exemple qui précède, je peux définir une variable appelée MUOHOME dans .bashrc :

export MUOHOME=$HOME/web/muo/rsmuo/docs

Pour pouvoir placer cette variable dans mon alias, je dois maintenant utiliser des guillemets doubles :

alias upmuo="rsync -e ssh -z -t -r -vv --progress $MUOHOME muo:/www/mandrivauser/docs"

faute de cela l'alias chercherait un répertoire ou un fichier appelé $MUOHOME.


Notez que vous pouvez définir plus d'un alias pour une même commande qui sera utilisée de différentes façons selon l'alias qui la lancera (avec des options différentes, par exemple).

Pérenniser un alias

Il est possible de créer des alias « à la volée » sur la ligne de commande avec la commande alias, juste pour la durée de la session du shell en cours.

On peut aussi rendre ces alias permanents en en créant une liste dans une section de personnalisation, à la fin du fichier de configuration du shell d'un utilisateur ~/.bash_profile, ou bien à la fin du fichier /etc/bashrc (dans ce dernier cas, ils seront disponibles pour tous les utilisateurs et pour root).

Les alias par défaut définis par Mandriva se trouvent, quant à eux, dans le fichier /etc/profile.d/alias.sh (consultez-le avant de créer vos propres alias).

Désactiver temporairement un alias

Pour désactiver un alias, taper simplement :

unalias alias

(où alias doit être remplacé par un certain alias actif sur votre système, qui sera alors désactivé pour la durée de la session du shell en cours).

Pour désactiver un alias de façon strictement ponctuelle, juste dans le cadre d'une unique ligne de commande, vous pouvez simplement vous contenter de mettre le nom de la commande entre guillemets, dès la prochaine commande l'alias sera à nouveau disponible, sans que vous ayez à relancer une nouvelle session du shell. Pour un exemple, voir cette section.

La liste de tous les alias

Lancer simplement :

alias

entraînera l'affichage de la liste de tous les alias de votre système.


Regardez votre -.bashrc et /etc/profile.d/alias.sh, vous pourrez constater que des alias y sont déjà définis.

Précautions

Bien entendu avant de créer un alias, vous devez vous assurer que votre alias n'est pas le nom de quelqu'autre programme : quelque chose comme alias rm='ls -l' ne marchera pas. Pour vérifier que le nom de votre futur raccourci est bien disponible, vous pourriez être tenté de le taper « pour voir » mais, après tout, ce serait risqué : si cette commande existe, rien ne dit que vous souhaitiez qu'elle soit exécutée ! Le mieux, si vous envisagez de créer un alias choin est de taper la commande :

type choin

si vous obtenez un message d'erreur de ce genre :

bash: type: choin: not found

et dans ce cas seulement, vous pourrez considérer que choin est disponible et vous pourrez en faire un alias.


Notez que, sur un système Linux, chaque utilisateur dispose d'un ensemble de commandes qui peut être en partie différent d'un utilisateur à l'autre, en particulier, on le sait, certaines commandes sont réservées au superutilisateur root. Par conséquent, si vous souhaitez créer un alias (ou une fonction) pour un certain utilisateur (ou pour root), vous devez avant d'effectuer l'essai du nom choisi pour votre alias avec la commande type, vous connecter sous l'identité de l'utilisateur approprié. Sinon une commande peut vous être rapportée à tort par type comme inexistante.

Exemples d'alias

Vous trouverez une liste d'alias proposés par défaut sous Mandriva à cette section #Les raccourcis clavier du shell.


Voici quelques autres alias qui pourraient vous être utiles (mais n'oubliez pas les guillemets !) :

  • alias oo='openoffice.org2.2 -writer '

Pour lancer à partir de la console le module de traitement de texte Writer d'OpenOffice.org (version 2.2)

  • alias rpmq='rpm -qa | grep'

La commande rpmq chaîne affichera alors la liste de tous les RPM installés dont le nom contient chaîne.

  • alias maj='urpmi --auto-update -v --auto --keep --no-uninstall'

Pour une mise à jour de routine de votre Mandriva.

  • alias use='du --max-depth=1 | sort -n | less'

use vous donnera une liste, défilant page par page, des tailles des sous-répertoires du répertoire courant, affichée par ordre décroissant de taille

  • alias dkd='cd /usr/src/linux/Documentation'

Des répertoires fréquemment utilisés peuvent aussi être inclus dans un alias. D'autres candidats pourraient être par exemple les répertoires de /mnt. Les répertoires inclus dans un alias peuvent aussi être des répertoires de médias amovibles : alias dlm='/mnt/cdrom/Mandriva/RPMS/'


Un petit « truc » pour aider la mémoire : faites en sorte que tous vos alias dotés de fonctions similaires commencent par la même lettre. Par exemple, faites commencer tous vos alias de répertoire par la lettre d.


Je suis sûr que vous trouverez toute sorte de possibilités d'utilisation de ce mécanisme de création d'alias.

Les macros inputrc

Notez pour terminer qu'il est possible de créer une autre sorte d'alias, appelés usuellement des macros, en éditant le fichier /etc/inputrc ou en créant un/des fichier(s) ~/.inputrc. Voir la section Les fichiers de configuration du shell#Créer des raccourcis clavier pour la console avec inputrc.

Les fonctions

Introduction

L'écriture de fonctions pour le shell est un sujet qui est aux confins de l'écriture des scripts, ce qui est hors de la portée de cet article (et de la mienne aussi ;-). En fait les fonctions du shell sont des scripts, mais elles ont l'avantage d'être préchargées et exécutées dans le shell courant (alors qu'un script ouvre un sous-shell au minimum).

Définir une fonction, c'est créer une sorte de nouvelle commande du shell, un peu comme le fait un alias, mais on peut faire avec les fonctions un tas de choses que l'on ne peut pas faire avec les alias, comme nous allons le voir.

Un exemple de fonction : apros

Voici notre fonction :

function apros() { apropos $1 | egrep -v '\(3|\(9|\(n\)'; }

Ceci définit une nouvelle commande, appelée apros.

apros nom exécute apropos nom (commande de recherche dans les pages de man) et en envoie la sortie, grâce au tube (|) à egrep qui élimine (grâce à l'option -v) toutes les pages de man des sections 3, 9 et n, lesquelles ne sont généralement pas très intéressantes pour l'utilisateur lambda et tendent plutôt à rendre confuse la sortie de la commande apropos. Plus précisément, egrep élimine toutes les lignes envoyées par la commande apropos qui contiennent ou bien la suite de caractères (3 oub bien la suite (9 ou bien la suite de caractères (n). Le « ou bien » correspond dans le motif à la barre verticale |. Vous trouverez plus bas des détails supplémentaires sur tout cela.


Les fonctions peuvent prendre plusieurs arguments, avec chacun leur position propre.


$1 est ce qu'on appelle un « paramètre positionnel » (anglais « positional parameter »), qui contient la premier argument qu'on fournira à la fonction lorsqu'on la lancera. Bien sûr il peut y en avoir d'autres.


Supposons par exemple qu'on ait écrit la fonction apros ainsi (où $2 représente le second argument qui sera fourni à la fonction quand on la lancera) :

function apros() { apropos $1 | egrep -v "\($2"; }

Alors, si maintenant vous lancez la commande comme ceci :

apros nom numero_de_section_de_man

elle effectue une recherche de nom, tout en excluant toutes les pages de man des sections ayant le numéro numero_de_section_de_man :

apros menu 3

renvoie tous les titres des pages de man qui contiennent menu, sauf ceux de la section 3 (programmation). Notez que vous devez protéger les caractères tapés deux fois et que vous devez utiliser des guillemets doubles :


  • Vous devez placer entre guillemets le motif de recherche fourni à egrep - autrement dit dans notre exemple: \($2 - pour le protéger du shell.
  • Et c'est entre des guillemets doubles (et non simples) que le second paramètre positionnel - $2 - doit être situé pour pouvoir être interprété correctement.
  • Vous devez aussi protéger spécifiquement la parenthèse (par une barre oblique inverse '\') pour signaler à egrep qu'elle doit être comprise littéralement et non comme un caractère de contrôle spécial.

egrep est une variante de la commande grep. Le motif \(3|\(n\) dans notre première définition de la fonction apros est ce qu'on appelle une « expression rationnelle » (ou une expression régulière ou une regexp). Vous en trouverez d'autres exemples dans la page sur grep. egrep accepte directement comme arguments des « expressions rationnelles étendues » dans lesquelles les parenthèses ont une fonction spéciale et doivent être protégées par la barre oblique inverse pour être considérées comme de simples caractères, avec grep où ce n'est pas le cas, on aurait écrit :

grep -v '(3\|(n)'

avec une barre oblique inverse devant la barre verticale mais pas devant les parenthèses… Et dans notre seconde version de apros l'appel à egrep aurait pu être remplacé par cet appel à grep :

grep -v "($2"
À noter !

Pour expérimenter la fonction apros, vous pouvez effectuer un simple copier-coller : sélectionnez la ligne de définition de la fonction ci-dessus dans cette page, faites un <Ctrl-c>, puis dans l'utilitaire Konsole de KDE, déroulez le menu Edition et choisissez Coller. Appuyer sur la touche <ENTREE> : la fonction est maintenant active pour la durée de votre session du shell courant.

Pour vous rendre compte de l'allègement obtenu par notre fonction, comparez, par exemple les affichages de : apropos link et apros link, ou encore ceux de apropos copy et de apros copy.


Et... hum, ne vous découragez pas déjà, enfin !!


Compliqué, pas vrai ? ;-).

Conseils généraux

Pour que les fonctions que vous avez créées soient disponibles en permanence, vous les mettrez dans votre section de personnalisation à la fin du fichier de configuration du shell ~/.bash_profile (ou, éventuellement, à la fin du fichier /etc/bashrc, si vous souhaitez qu'elles soient disponibles pour tous les utilisateurs du système).

En général, vous ne souhaiterez pas que votre fonction remplace une commande déjà existante. Pour savoir si c'est le cas, utilisez comme nous l'avons expliqué dans la section précédente sur les alias, la commande type, avec le nom que vous vous proposez de donner à votre fonction, afin de déterminer s'il est bien disponible.

Vous trouverez d'autres conseils bien utiles et des exemples concrets de fonctions dans Ecrire un script shell#Utiliser les fonctions du shell.

FAQ

Comment couper ce &*#! bip ?

Avec la commande :

setterm -blength 0

Pourquoi ai-je ce message : bash: commande: command not found ?

Vous avez peut-être fait une faute de frappe, si ce n'est pas le cas, peut-être que la commande que vous tentez d'exécuter est située dans un répertoire qui ne fait pas partie de votre $PATH. Tapez le chemin complet de la commande. Si vous êtes dans le même répertoire que la commande, faites :

./commande

Pourquoi ai-je ce message : bash: commande: Permission denied ?

Pour qu'un fichier soit exécutable, la permission d'exécution doit être activée pour l'utilisateur qui veut exécuter le fichier. Faites :

chmod +x fichier

Si cela ne marche pas lisez l'article sur les permissions.

Le bit d'exécution est activé, j'ai les permissions d'exécution mais la permission m'est refusée quand même. Pourquoi ?

Vérifier dans /etc/fstab l'entrée de la partition où se trouve ce fichier. Vérifiez qu'il ne contient pas l'option noexec. S'il contient l'option user, l'option exec doit être activée aussi.

Comment modifier les couleurs des listes de fichiers affichées par ls ?

Copier /etc/DIR_COLORS dans votre répertoire personnel et renommez-le .dir_colors. Tout ce dont vous avez besoin se trouve dans ce fichier (mais en anglais...).

Plus concrètement, la première étape devrait être de taper la commande de copie suivante dans une console, suivie d'une pression sur la touche ENTREE, en étant connecté comme simple utilisateur (et surtout pas sous root) :

cp /etc/DIR_COLORS  ~/.dir_colors

N'oubliez pas le point devant .dir_colors !

Ensuite lisez votre .dir_colors avec soin. La commande

cat ~/.dir_colors | less

devrait y suffire.

Ceci fait, commencez à modifier .dir_colors dans un éditeur de texte (Emacs, vi, gedit, kwrite, kate ou tout autre mais surtout pas dans un traitement de texte, comme OpenOffice.org ou KOffice). Procédez progressivement en introduisant les modificaitons une à une et contrôlant leur effet sur l'affichage de ls en console. Vous pourrez toujours retrouver les valeurs par défaut à partir du fichier /etc/DIR_COLORS qui reste inchangé.

D'un autre côté, si vous êtes dans un environnement réellement multiutilisateur et que vous tenez à imposer vos modifications à tous les utilisateurs du système, vous devrez modifier directement le fichier /etc/DIR_COLORS. Mais attention, dans ce cas, avant tout, créez une copie de sauvegarde du fichier, en tapant la commande suivante, que vous pouvez exécuter comme simple utilisateur :

cp -p /etc/DIR_COLORS /etc/DIR_COLORS_VIEUX

(l'option -p garantit que la copie de sauvegarde aura les mêmes propriétaires, permissions et horodatage que l'original).

J'ai mis un script choin dans mon répertoire personnel bin, mais chaque fois que j'essaie de le lancer c'est une commande différente qui s'appelle elle aussi choin qui est lancée. Pourquoi ?

Jetez un coup d'oeil à votre $PATH et vous verrez que votre répertoire bin personnel est situé tout à la fin ou très près de la fin du $PATH. Le shell cherche la commande en examinant les répertoires énumérés dans le $PATH les uns après les autres. Dès qu'il trouve une commande qui correspond à ce qui a été tapé, il l'exécute. Si votre système contient une commande qui a le même nom que votre script, il est donc probable que c'est elle qui sera exécutée et non votre script. Conclusion : renommez donc votre script !

Que signifie bash: commande: bad interpreter ?

Ceci se produit généralement avec des installations de binaires de logiciels tiers ou avec des applications Java. Ces applications ont besoin d'un shell particulier, ainsi au lieu de

commande

vous devez lancer

sh commande

Mon terminal se bloque chaque fois que je tape CTRL + s

Eh bien ne le faites pas ! ;-). <CTRL s> envoie une commande de bloquage du défilement au terminal. Pour le débloquer, il faut simplement faire <CTRL q>. En fait, ceci ne semble se produire que dans les consoles textes (les tty, celles auxquelles on accède par une combinaison de touches CTRL+ALT+Fn), dans les consoles graphiques (sous KDE par exemple) <CTRL s> permet de faire une recherche « vers l'avant » dans l'historique des lignes de commande (à condition d'avoir d'abord fait une recherche vers l'arrière avec <CTRL r>)...

Autres sources d'information sur le shell

Que faire en sortant d'ici ?

Cet article n'est qu'un début. Apprendre à écrire des scripts peut vous permettre d'automatiser de nombreuses tâches, de corriger des erreurs dans les scripts faits par d'autres et d'habituer votre système Mandriva Linux à se plier à vos désirs (quasiment) en tout. Si vous prévoyez d'apprendre un langage de programmation plus complexe, apprendre à écrire des scripts peut être un bon début car les concepts de base seront voisins.


Voici d'abord une série de liens vers des pages de l'actuel Wiki sur des points particuliers :


Et d'autres liens utiles sur Internet :

Tutoriels divers en français sur le shell
Le Wiki de ceux qui aiment la ligne de commande
Petit Manuel de référence du shell
Lea-Linux : le shell ou le retour du C:
Guide avancé d'écriture des scripts Bash par Mendel Cooper remarquable ouvrage, à la fois clair et accessible et en même temps d'une grande richesse, qui vous permetra d'aborder la programmation des scripts.
Bash Reference Manual (manuel officiel en anglais)

Et avant tout : de la pratique, de la pratique de la pratique. Lisez des scripts écrits par d'autres et essayez de comprendre ce qu'ils font. Ne lancez pas vos essais de scripts sous root. Et… amusez-vous bien.