Pour aller plus loin avec la ligne de commande

Une commande peut être interne (builtin) au shell, ou externe. Dans le premier cas la commande est interprétée par le shell, dans l'autre il peut s'agir de n'importe quel fichier exécutable stocké dans l'arborescence. L'algorithme d'interprétation des commandes devient :

La recherche de l'exécutable correspondant à une commande externe consiste en l'examen d'un ensemble de répertoires susceptibles de contenir l'exécutable en question.

Cette liste de répertoires définie lors de la configuration du système est stockée dans une variable d'environnementRudiments sur les variables d'environnement nommée PATH. Dans le shell utilisé par votre serviteur :

$ type cat
cat is /bin/cat
$ type echo
echo is a shell builtin
$

La commande type nous informe que echo est une commande interne et que la commande cat ne l'est pas (i.e. est un programme dans le répertoire /bin). type est une commande interne du shell bash. L'équivalent pour la famille des C-shells est which. 

Le shell et les commandes exécutées peuvent informer l'utilisateur qu'une erreur s'est produite lors de l'exécution d'une commande. Cette information concernant l'erreur se fait par un canal appelé le flux d'erreur qui est par défaut redirigé sur votre écran. Il existe au moins quatre situations où le shell et les commandes renvoient une erreur :

• la commande n'existe pas :

$ youpla
bash: youpla: command not found
$

• l'argument spécifié ne correspond à aucun fichier :

$ cp mlkj essai.tex
cp: mlkj: No such file or directory
$

• l'utilisateur ne possède pas les droits suffisants :

$ cp g.dat /
cp: cannot create file `/g.dat': Permission denied
$

• la commande n'est pas utilisée avec les bonnes options :

   

  Sélectionnez

  $ cat -l fichier.tmp
  cat: invalid option -- l
  Try `cat --help' for more information.
  $

À l'instar des boîtes de dialogue d'avertissement ou d'erreur qui surgissent dans les environnements graphiques, il est important de lire attentivement les messages pour comprendre pourquoi une commande échoue. 

On peut composer deux ou plusieurs commandes à l'aide du caractère « ; » :

$ ls guide-unix.tex ; echo bonjour
guide-unix.tex
bonjour
$

Notons au passage que la commande echo affiche à l'écran la chaîne de caractère qui suit. Il existe deux autres opérateurs permettant de combiner deux commandes :

• l'opérateur &&

  • commande₁ && commande₂

  exécute commande₂ si commande₁ s'exécute sans erreur ;

• l'opérateur || commande₁ || commande₂ exécute commande₂ si commande₁ renvoie une erreur.

Lorsqu'il est dit ci-dessus que la commande « renvoie une erreur », il s'agit plus précisément de la situation où la commande retourne une valeur différente de 0 (voir aussi § 5.2.4.cLes commandes renvoient une valeur !).

Pour désigner un élément de l'arborescence en utilisant une référence absolue, on part de la racine du système de fichier et on « descend » jusqu'au fichier ou répertoire.

De cette manière on désignera les fichiers bidule.dat et truc.txt de l'arborescence donnée en exemple à la figure 2.2 par :

/users/bidule.dat
/home/eleves/truc.txt

Le caractère / joue deux rôles :

• d'une part il désigne le répertoire racine (root directory en anglais) ;
• d'autre part il fait usage de séparateur de répertoires dans l'écriture des références de fichiers et répertoires.

Pour désigner un répertoire on utilisera le même principe, ainsi les répertoires eleves et users ont comme référence absolue :

/home/eleves
/users

Il est souvent utile de désigner les fichiers et répertoires grâce à une référence relative. Dans ce cas on référencera un fichier ou un répertoire relativement à un répertoire de base. Par exemple :

• si /users est le répertoire de base, alors il est possible de référencer les fichiers bidule.dat et truc.txt comme suit :

   

  Sélectionnez

  ./bidule.dat
  ../home/eleves/truc.txt

• si /home est le répertoire de base, alors on peut les référencer comme suit :

../users/bidule.dat
./eleves/truc.txt

Deux répertoires particuliers existent dans chaque répertoire :

• le répertoire . qui désigne le répertoire courant ;
• le répertoire .. qui désigne le répertoire parent.

On pourra noter que l'écriture ./bidule.dat est redondante et peut être abrégée en bidule.dat. Enfin, le répertoire de référence dont il a été question est souvent le répertoire dit courant ou répertoire de travail (working directory en anglais). C'est le répertoire associé à chaque processus. C'est aussi le répertoire « dans lequel on se trouve » lorsqu'on lance une commande.

Le répertoire « . » a également une utilisation importante lorsqu'on veut exécuterExécution un programme situé dans le répertoire courant, ce dernier ne se trouvant pas dans la liste des répertoires de recherche de la variable PATH.

Dans toutes les commandes unix qui manipulent des fichiers ou des répertoires, l'utilisateur est libre de désigner ces fichiers ou répertoires par le truchement des références absolues ou des références relatives. Le choix (relative ou absolue) est souvent dicté par le nombre le plus faible de touches de clavier à presser… 

Les droits par défaut sont définis par l'intermédiaire d'un masque de création de fichier. En jargon unix, ce masque est appelé umask pour user file creation mask. Ce masque est associé à un utilisateur et précise quels droits aura par défaut un fichier lors de sa création. Pour connaître son umask :

$ umask -S
u=rwx,g=rx,o=rx
$

Ce qui signifie qu'un fichier est créé avec par défaut :

• pour le propriétaire : tous les droits ;
• pour le groupe :
• droits en lecture ;
• droits en lecture et exécution pour les répertoires ;
• idem pour les autres.

Nous prendrons comme hypothèse pour nos études de cas que l'umask du système est celui donné par la commande umask -S ci-dessus. Créons un répertoire et un fichier dans ce répertoire :

$ mkdir echange
$ touch echange/donnees.txt
$

La commande touch change les attributs de date d'un fichier en le créant s'il n'existe pas. On peut alors examiner les droits sur ces fichiers :

$ ls -ld echange
drwxr-xr-x 2 vincent users 4096 Nov 18 23:06 echange
$ ls -l echange
-rw-r--r-- 1 vincent users 6 Nov 15 21:22 donnees.txt
$

En considérant le répertoire comme un « catalogue » contenant une liste de fichiers, on peut voir les trois types de droits comme suit :

• Lecture : compulser le catalogue, c'est-à-dire lister le contenu du répertoire avec la commande ls par exemple.
• Écriture : modifier le catalogue, donc effacer les fichiers, les renommer, les déplacer.
• Exécution : cet attribut permet à un utilisateur de pénétrer dans ce répertoire et d'accéder aux fichiers qui s'y trouvent.

Voyons plus précisément grâce à un exemple :

$ chmod g-r echange
$ ls -ld echange
drwx--xr-x 2 vincent users 4096 Nov 20 18:03 echange
$

la commande chmod ci-dessus retire aux membres du groupe users le droit de lire le répertoire echange. C'est pourquoi lorsqu'un utilisateur autre que vincent (appelons-le rene), mais du groupe users, lance la commande :

$ ls ~vincent/echange
ls: /home/vincent/echange/: Permission denied
$

elle échoue, faute de privilèges suffisants. Ici c'est le droit d'examiner le contenu du répertoire qui n'est pas accordé. Par contre, la commande :

$ cat ~vincent/echange/donnees.txt
$

est légitime, puisque l'attribut x pour le groupe du répertoire echange est présent et permet à l'utilisateur rene d'accéder aux fichiers qu'il contient. C'est pourquoi, si l'on supprime aussi le droit d'exécution sur le répertoire echange pour le groupe users, comme ceci :

$ chmod g-x echange
$ ls -ld echange
drwx---r-x 2 vincent users 4096 Nov 20 18:03 echange
$

la commande suivante, lancée par rene échoue faute de droits suffisants :

$ cat ~vincent/echange/donnees.txt
cat: /home/vincent/echange/donnees.txt: Permission denied
$

Il faut comprendre qu'un utilisateur ayant les droits d'écriture sur un répertoire peut effacer tous les fichiers qu'il contient quels que soient les droits et propriétaires de ces fichiers.

Avec le umask du paragraphe précédent, les membres du groupe propriétaire sont autorisés à lire un fichier nouvellement créé dans un répertoire nouvellement créé. En effet :

1. le répertoire qui contient le fichier est exécutable pour le groupe en question ;
2. le fichier est lisible pour le groupe.

Pour autoriser un membre du groupe propriétaire du fichier donnees.txt du répertoire echange à modifier un fichier il suffit d'activer l'attribut w pour le groupe avec la commande chmod (en supposant que le répertoire courant est echange) :

$ chmod g+w donnees.txt
$ ls -l donnees.txt
-rw-rw-r-- 1 vincent users 40 Nov 2 18:03 donnees.txt
$

Pour des raisons diverses, on peut vouloir interdire la lecture d'un fichier aux utilisateurs n'appartenant pas au groupe du fichier. Pour ce faire, la commande :

$ chmod o-r donnees.txt
$ ls -l donnees.txt
-rw-rw---- 1 vincent users 0 Nov 20 18:03 donnees.txt
$

interdit aux « autres » l'accès en lecture à donnees.txt.

Lorsqu'un fichier est supprimé du système de fichier, le répertoire qui le contient est également modifié, car ce dernier contient la liste des fichiers qu'il héberge. Par conséquent, il n'est pas nécessaire d'activer l'attribut w sur un fichier pour pouvoir l'effacer, il faut par contre s'assurer que cet attribut est actif pour le répertoire qui le contient. Dans le cas qui nous préoccupe, la commande :

$ ls -ld echange
drwx---r-x 2 vincent users 4096 Nov 20 18:03 echange
$ chmod g+rwx echange
$ ls -ld echange
drwxrwxr-x 2 vincent users 4096 Nov 20 18:03 echange
$

accorde tous les droits (dont l'attribut w) au groupe propriétaire sur le répertoire echange ; ce qui permet à l'utilisateur rene de pouvoir effacer le fichier donnees.txt.

La commande chmod telle qu'on l'a vue jusqu'à présent obéit à la syntaxe suivante :

Les arguments de la commande chmod peuvent être constitués de plusieurs blocs p%a. Le cas échéant ils doivent être séparés par des virgules. Les commandes suivantes sont donc correctes :

$ chmod o-rwx bidule
$ chmod g+rx bidule
$ chmod -w,o+x bidule
$ chmod a+r bidule
$

Dans l'ordre, chacune des commandes précédentes :

• enlève tous les droits aux autres ;
• donne les droits en lecture et exécution pour les membres du groupe propriétaire ;
• enlève le droit en écriture pour tout le monde et rajoute le droit en exécution pour les autres ;
• donne à tout le monde le droit en lecture.

On notera donc que sans indication de propriétaires, tous sont concernés et ceci en accord avec le umask. D'autre part l'option -R de la commande chmod permet d'affecter le mode spécifié de manière récursive aux fichiers contenus dans les sous-répertoires.

Mais venons-en au fait : certains puristes utilisent ce qu'on appelle la notation octale pour positionner les droits d'un fichier. Cette notation consiste a coder chaque bloc rwx du bloc de droits en une donnée numérique de la manière suivante :

On a alors, par exemple :

- -rwx------ codé par 700 ;
- -rw-r-xr-x codé par 655 ;
- -rw-r--r-- codé par 644.

Ce codage octal peut être utilisé en lieu et place des symboles gor et rwx avec la commande chmod. Il est également intéressant de noter qu'on peut afficher le umask en notation octale :

$ umask
022
$

Cette valeur est le complément par rapport à 777. Avec un tel masque, les fichiers sont créés avec les permissions 755. 

L'opération qui consiste à relier un fichier (un ensemble d'octets sur un disque) à un nom sur l'arborescence est précisément la création d'un lien physique. Soit le fichier ~/doc/unix/guide.tex :

$ cd ~/doc/unix
$ ls -li guide.tex
38564 -rw-r--r-- 1 vincent users 18114 Nov 7 22:44 guide.tex
$

on constate que ce fichier (créé par un éditeur de texte) a pour inode 38564, et ne possède qu'un lien (~/doc/unix/guide.tex).

On peut créer un nouveau lien sur ce fichier éventuellement dans un répertoire différent si ce répertoire est sur la même partition que le fichier guide.tex, grâce à la commande ln (link) dont la syntaxe est :

• ln cible du lien nom du lien

Par exemple :

$ cd ~/tmp
$ ln ~/doc/unix/guide.tex unix.tex
$ ls -li unix.tex
38564 -rw-r--r-- 2 vincent users 18114 Nov 7 22:44 unix.tex
$

on peut alors constater (figure 2.4) que le fichier unix.tex possède maintenant deux liens physiques. Dans cette situation, il y a donc une seule représentation des données sur le disque - ce qui est confirmé par l'inode qui est identique (38564) pour les deux liens - et deux noms associés à cette représentation :

1. ~/doc/unix/guide.tex
2. ~/tmp/unix.tex

Ce qui implique que l'on peut modifier le fichier par le biais de l'un ou l'autre des liens. Pour ce qui est de la suppression d'un lien, la règle est la suivante :

1. tant que le nombre de liens physiques sur le fichier en question est strictement supérieur à 1, la commande rm aura pour effet la suppression du lien et non des données.
2. lorsque le nombre de liens physiques est égal à 1, rm efface effectivement les données, puisqu'il n'y a plus qu'un lien unique sur celles-ci.

Pour être très précis, si le fichier en question est ouvert par au moins un processus, le lien disparaîtra après la commande rm mais l'espace qu'occupent les données ne sera libéré que quand le dernier processus ayant ouvert le fichier se terminera.

Lorsque l'on veut lier un fichier par l'intermédiaire d'un lien ne se trouvant pas sur la même partition que le fichier lui-même, il est nécessaire de passer par l'utilisation d'un lien dit symbolique. Nous allons par exemple créer un lien symbolique sur notre fichier guide-unix.tex depuis le répertoire /tmp se trouvant sur une autre partition :

$ cd /tmp
$ ln -s ~/doc/unix/guide.tex test.tex
$ ls -l test.tex
lrwxrwxrwx 1 vincent users 32 Nov 21 16:41 test.tex -> /hom
e/vincent/doc/unix/guide.tex
$

Les liens résultants sont indiqués à la figure 2.5.

On remarquera les particularités d'un lien symbolique :

• c'est un fichier différent de celui sur lequel il pointe ; il possède son propre inode :

$ ls -i test.tex
23902 test.tex
$

• le fichier contient une référence sur un autre fichier, ce qui explique par exemple que la taille du lien symbolique test.tex est de 32, qui correspond aux nombres de caractères du chemin du fichier auquel il se réfère ;

• un lien symbolique est un fichier spécial dont on ne peut changer les permissions, ce qui est indiqué par le bloc de droits :

lrwxrwxrwx

La plupart des opérations sur le lien symbolique est effectuée sur le fichier sur lequel il pointe. Par contre la suppression de ce lien obéit aux règles suivantes :

1. la commande rm supprime le lien symbolique lui-même - qui est un fichier à part entière - et n'a pas d'influence sur le fichier auquel il se réfère ;
2. par conséquent, si on supprime le fichier, le lien symbolique existe toujours et pointe sur un fichier qui n'existe pas.

Enfin la dernière particularité du lien symbolique (qui le distingue du lien physique) provient du fait qu'il est possible de créer un tel lien sur un répertoire. Par exemple :

$ cd
$ ln -s /usr/share/texmf/tex/latex macros
$ ls -l macros
lrwxrwxrwx 1 vincent users 26 Nov 21 17:02 macros -> /usr/sh
are/texmf/tex/latex
$

il est alors possible d'utiliser le lien symbolique comme un raccourci vers un autre répertoire. Notons à ce sujet que la notion de lien symbolique d'unix, peut s'apparenter à celle de raccourci de Windows®. Cependant l'utilisateur attentif de ce dernier système aura remarqué que les raccourcis ne constituent juste qu'une aide à l'environnement graphique, mais qu'il est impossible de traiter le raccourci comme un véritable fichier ou répertoire le cas échéant.

Nous avons vu à partir de la section 2.3.3Privilèges consacrée aux privilèges sur les fichiers et répertoires que par défaut un système unix attache trois privilèges à un fichier :

1. les privilèges de l'utilisateur propriétaire.
2. ceux du groupe propriétaire.
3. ceux des autres.

Par conséquent la finesse du réglage des accès ne peut se faire qu'au niveau du groupe.

En d'autres termes pour rendre un fichier accessible en lecture et écriture à un utilisateur et uniquement à lui, il n'y a pas d'autre solution que de créer un groupe auquel appartient, puis d'accorder les droits de lecture et d'écriture au groupe.

Imaginons que deux utilisateurs - dont les noms de connexion sont andy et debrah - veuillent collaborer sur le contenu d'un fichier poodle.dat. Tout d'abord, l'administrateur doit créer un groupe (nommons-le zircon) puis faire en sorte que andy et debrah deviennent membres de ce groupe. Ensuite l'utilisateur initialement propriétaire du fichier poodle.dat (par exemple andy) doit positionner les privilèges sur celui-ci :

$ ls -l poodle.dat
-rw-r--r-- 1 andy users 3100 2009-05-11 22:51 poodle.dat
$ chgrp zircon poodle.dat
$ chmod g+rw poodle.dat
$ ls -l poodle.dat
-rw-rw-r-- 1 andy zircon 3100 2009-05-11 22:51 poodle.dat
$

À partir de maintenant, l'utilisateur debrah peut lire et modifier le contenu du fichier poodle.dat.

Le problème ici est que la création du groupe n'est possible que pour l'administrateur du système qui seul peut ajouter un nouveau groupe d'utilisateurs. En outre si un autre utilisateur souhaitait se greffer au projet, il faudrait à nouveau lui faire une demande pour ajouter le nouveau venu au groupe. On voit donc clairement que la gestion des privilèges proposée par défaut dans unix a l'inconvénient d'être trop statique pour l'exemple présenté ci-dessus.

Nous vous proposons donc ici de découvrir quelques commandes permettant de régler les privilèges plus finement et de manière plus autonome. La gestion des ACL sous unix repose essentiellement sur deux commandes :

• getfacl examen des autorisations d'un fichier ;
• setfacl positionnement de ces autorisations.

/dev/sdb5 /home ext3 acl,defaults 0 2

Accorder des droits à un utilisateur - Reprenons l'exemple de nos deux compères andy et debrah souhaitant tous deux collaborer sur le fichier poodle.dat :

$ ls -l poodle.dat
-rw-r--r-- 1 andy users 3100 2009-05-11 22:51 poodle.dat
$

Pour autoriser debrah à lire et modifier le fichier en question, andy devra taper :

$ setfacl -m u:debrah:rw poodle.dat
$

La syntaxe

• setfacl -m u:user:perm fichier

permet donc de modifier (c'est le sens de l'option m) les autorisations de l'utilisateur user (argument u:). Les autorisations perm peuvent être définies en utilisant la notation symbolique présentée au paragraphe 2.3.3Privilèges.

Comme la commande chmod, setfacl autorise l'option -R pour accorder les droits spécifiés à tous les fichiers et sous-répertoires, récursivement.

Examiner les autorisations associées à un fichier L'option -l de la commande ls propose un affichage légèrement modifié lorsque des autorisations ACLs sont associées à un fichier :

$ ls -l poodle.dat
-rw-rw-r--+ 1 andy users 3100 2009-05-11 22:51 poodle.dat
$

Notez la présence du signe +. La commande getfacl permet de lister les permissions associées :

$ getfacl poodle.dat
# file: poodle.dat
# owner: lozano  <----------------------------------- propriétaire
# group: lozano  <---------------------------- groupe propriétaire
user::rw-  <------------------------------- droits du propriétaire
user:debrah:rw-  <----------------- droits de l'utilisateur debrah
group::r--  <----------------------- droits du groupe propriétaire
mask::rw-  <----------------------------------------- cf. plus bas
other::r--  <----------------------------------- droits des autres
$

Accorder des droits par défaut dans un répertoire - Grâce à l'option -d de la commande setfacl on peut accorder des droits par défaut à un répertoire. En reprenant l'exemple précédent, la commande :

$ setfacl -d -m u:muffin:rw .
$

permet d'autoriser la lecture et l'écriture à l'utilisateur muffin pour tous les fichiers créés dans le répertoire courant. En d'autres termes, tous les fichiers créés par la suite seront lisibles et modifiables par l'utilisateur muffin.

Attention, la commande de l'exemple ci-dessus n'accorde pas à l'utilisateur muffin de créer des fichiers dans le répertoire courant.

Enfin, les droits par défaut peuvent être retirés avec l'option -k. Ici la commande :

$ setfacl -k .
$

supprime les droits par défaut sur le répertoire courant.

Révoquer des droits - Pour supprimer les droits ajoutés avec la setfacl et son option -m on peut utiliser :

• l'option -b pour supprimer tous les droits de type ACL
• l'option -x pour supprimer une entrée, par exemple :

$ setfacl -x u:debrah poodle.dat
$

révoque les droits accordés sur le fichier poodle.dat à l'utilisateur debrah.

Masque ACL - Lorsqu'au moins un privilège de type ACL a été accordé à un fichier, un masque est créé contenant l'union de toutes les autorisations. Ce masque est construit automatiquement, ainsi :

$ setfacl -m u:dinah:r righthereonthe.floora
$ setfacl -m u:moe:r righthereonthe.floora
$ setfacl -m u:hum:rw righthereonthe.floora
$

Le masque créé et affiché par la commande getfacl sera :

$ getfacl righthereonthe.floora
[...]
user::dinah:r--
user::moe:r--
user::hym:rw-
[...]
mask::rw-  <--------------- union des trois permissions précédentes
[...]
$

L'intérêt de ce masque réside dans le fait qu'il peut être modifié pour appliquer une politique pour tous les utilisateurs. Par exemple pour ne conserver que le droit en lecture pour tous les utilisateurs ACL, on peut exécuter la commande suivante :

$ setfacl -m m::r righthereonthe.floora
$

J'ai lancé Emacs (éditeur de texte grâce auquel je tape ce document) dans une fenêtre xterm ; voici ce que me donne la commande ps dans cette fenêtre :

$ ps
PID TTY TIME CMD
1322 ttyp2 00:00:43 bash
1337 ttyp2 00:02:04 emacs
1338 ttyp2 00:00:00 ps
$

On obtient donc une liste dont la première colonne contient le pid de chaque processus, chacun de ces processus est associé au pseudoterminal du xterm désigné par ttyp2. La dernière colonne donne le nom de la commande associée au processus ; le temps donné ici est le temps CPU utilisé depuis le lancement de la commande.

On pourra noter que puisque la commande ps est lancée pour obtenir la liste des processus, son pid apparaît également dans la liste (ici pid 1338).

L'option x de la commande ps permet de lister les processus de l'utilisateur qui ne sont par rattachés au terminal courant(40):

$ ps x
PID TTY STAT TIME COMMAND
345 ? S 0:00 bash /home/vincent/.xsession
359 ? S 0:01 fvwm2
1254 ttyp0 S 0:00 lynx /usr/doc/vlunch/index.html
1354 ttyp3 S 0:00 xdvi.bin -name xdvi guide-unix.dvi
29936 ttyp2 R 0:00 ps -x
$

La nouvelle colonne STAT (status) donne l'état de chaque processus, ici S indique que le processus est endormi (sleeping), et R qu'il est prêt (runnable).

La syntaxe suivante permet d'obtenir la liste des processus lancés par un utilisateur du système :

$ ps -u rene
PID TTY TIME CMD
663 tty1 00:00:00 bash
765 ? 00:00:00 xclock
794 ttyp4 00:00:00 bash
805 ttyp4 00:00:00 mutt
$

L'utilisateur rene est donc connecté sur la première console virtuelle, a lancé une horloge du système X window, et est vraisemblablement en train de lire son courrier.

Enfin on veut parfois être en mesure de visualiser la liste de tous les processus sans critère restrictif de terminal ou d'utilisateur. Il y a encore une fois plusieurs voies pour atteindre ce but. La version de la commande ps de LINUX supporte plusieurs styles de syntaxes ; nous en donnons ci-dessous deux exemples :

$ ps aux
USER PID %CPU %MEM TTY STAT START TIME COMMAND
root 1 0.1 0.1 ? S 14:11 0:03 init [5]
root 2 0.0 0.0 ? SW 14:11 0:00 [kflushd]
root 3 0.0 0.0 ? SW 14:11 0:00 [kupdate]
root 4 0.0 0.0 ? SW 14:11 0:00 [kpiod]
root 5 0.0 0.0 ? SW 14:11 0:00 [kswapd]
root 210 0.0 0.3 ? S 14:12 0:00 syslogd -m 0
root 221 0.0 0.3 ? S 14:12 0:00 klogd
daemon 237 0.0 0.0 ? SW 14:12 0:00 [atd]
root 253 0.0 0.3 ? S 14:12 0:00 crond
root 284 0.0 0.3 ttyS0 S 14:12 0:00 gpm -t ms
$

Cette commande liste sur le terminal tous les processus du système - ici elle est raccourcie bien évidemment. Cette forme de listing fournit également la date de démarrage du processus (champ START), ainsi que le pourcentage de CPU et de mémoire utilisés (%CPU et %MEM respectivement).

Il est également intéressant de noter que l'on peut suivre la séquence de démarrage du système d'exploitation : le premier programme lancé porte le pid 1 et se nomme init. Les processus suivants concernent les services de base du système unix. Voici une autre manière d'obtenir la liste complète des processus :

$ ps -ef
UID PID PPID STIME TTY TIME CMD
root 1 0 14:11 ? 00:00:03 init [5]
root 2 1 14:11 ? 00:00:00 [kflushd]
root 3 1 14:11 ? 00:00:00 [kupdate]
root 4 1 14:11 ? 00:00:00 [kpiod]
root 5 1 14:11 ? 00:00:00 [kswapd]
root 210 1 14:12 ? 00:00:00 syslogd -m 0
root 221 1 14:12 ? 00:00:00 klogd
daemon 237 1 14:12 ? 00:00:00 [atd]
root 253 1 14:12 ? 00:00:00 crond
root 284 1 14:12 ttyS0 00:00:00 gpm -t ms
$

ici l'affichage est quelque peu différent. STIME est l'équivalent du START, et on a accès au ppid qui identifie le processus père d'un processus particulier. On remarquera dans cette liste que tous les processus sont des fils d'init - c'est-à-dire lancés par celui-ci. Ceci à l'exception d'init lui-même qui est le premier processus créé.

On peut se limiter à certaines informations en utilisant l'option o de la commande ps ; cette option permet de spécifier les champs que l'on désire voir s'afficher, par exemple :

$ ps -xo pid,cmd
PID CMD
346 [.xsession]
360 fvwm2 -s
363 xterm -ls -geometry 80x30+0+0
367 -bash
428 man fvwm2
$

n'affiche que le pid et la commande d'un processus. On a combiné ici l'option o avec l'option x vue précédemment. 

L'option --forest associée avec la commande précédente illustre l'arborescence des processus. On a isolé ici les processus associés à une session X ; on voit clairement grâce au « dessin » sur la partie droite, et à la correspondance entre pid et ppid, quelles sont les filiations des processus.

$ ps --forest -eo pid,ppid,cmd
PID PPID CMD
324 1 [xdm]
334 324 \_ /etc/X11/X
335 324 \_ [xdm]
346 335 \_ [.xsession]
360 346 \_ fvwm2 -s
448 360 \_ xterm -ls
451 448 | \_ -bash
636 451 | \_ ps --forest -eo pid,ppid,cmd
576 360 \_ /usr/X11R6/lib/X11/fvwm2/FvwmAuto
577 360 \_ /usr/X11R6/lib/X11/fvwm2/FvwmPager
$

Par défaut un processus lancé par un utilisateur a la même priorité que celui d'un autre utilisateur. Dans la situation où l'on désire lancer un processus « gourmand » sans gêner les autres utilisateurs du système, on peut utiliser la commande nice :

• $ nice -n priorité./groscalcul

où -20 ≤ priorité ≤ 19, 19 désignant la plus petite priorité (processus « laissant sa place » aux autres) et -20 la plus grande. Par défaut, les utilisateurs n'ont pas le droit d'utiliser une priorité négative, par conséquent tous les utilisateurs sont égaux face à l'utilisation des ressources de la machine.

Notons l'existence de la commande renice permettant de baisser la priorité d'un processus une fois qu'il est lancé. Par exemple, avec la commande :

$ renice -10 -p 4358
4358: old priority 0, new priority 10
$

on change la priorité du processus de pid 4358 en lui affectant la valeur 10. 

Lorsqu'on veut interrompre ou suspendre un processus, l'intervention revient toujours à envoyer ce qu'on appelle un signal au processus en question. Lorsqu'un processus reçoit un signal il interrompt le cours normal de son exécution et peut :

• soit s'arrêter, c'est le comportement par défaut ;
• soit exécuter une routine particulière que le concepteur de la commande aura eu soin de définir et reprendre son cours normal.

Selon la mouture de l'unix et de la plate-forme sous-jacente, on dispose d'une trentaine de signaux dont on peut avoir la liste avec la commande kill et l'option -l.

$ kill -l
1)  SIGHUP     2)  SIGINT    3)  SIGQUIT    4) SIGILL
5)  SIGTRAP    6)  SIGIOT    7)  SIGBUS     8) SIGFPE
9)  SIGKILL    10) SIGUSR1   11) SIGSEGV    12) SIGUSR2
13) SIGPIPE    14) SIGALRM   15) SIGTERM    17) SIGCHLD
18) SIGCONT    19) SIGSTOP   20) SIGTSTP    21) SIGTTIN
22) SIGTTOU    23) SIGURG    24) SIGXCPU    25) SIGXFSZ
26) SIGVTALRM  27) SIGPROF   28) SIGWINCH   29) SIGIO
30) SIGPWR
$

Tous ces signaux peuvent être détournés de manière à installer une routine à exécuter à la réception de ce signal ; ceci à l'exception du signal KILL (n°9) et du signal STOP (n°19) qui ne peuvent être détournés et donc ont toujours pour effet d'arrêter (respectivement d'interrompre) le processus.

Nous passerons ici en revue quelques utilisations de la commande kill. Dans un cadre très pratique, il y a trois situations vitales où il est nécessaire de connaître cette commande :

1. un programme « s'emballe », c'est-à-dire accapare les ressources mémoire ou cpu du système, il est alors nécessaire d'en stopper l'exécution ;
2. un programme utilise trop de ressources pour le confort des autres utilisateurs, il est nécessaire de l'interrompre momentanément ;
3. un programme ne répond plus aux sollicitations de l'utilisateur, il n'y a pas d'autres moyens que de l'interrompre en lui envoyant un signal de fin d'exécution.

Passons en revue ces trois situations en supposant que sur notre terminal la commande ps nous renvoie :

$ ps -o pid,pcpu,pmem,state,cmd
PID %CPU %MEM S CMD
2177 0.0 2.1 S -bash
2243 99.9 99.9 R winword-2005
2244 0.0 1.7 R ps -o pid,pcpu,pmem,state,cmd
$

Anti-emballement - On décide que le programme winword-2005 prend beaucoup trop de ressources - probablement à cause d'un bug - on intervient en décidant d'éliminer purement et simplement ce processus du système :

$ kill 2243
$

ce qui a pour effet d'envoyer le signal TERM au processus de pid 2243. Il se peut que l'envoi de ce signal soit sans effet si le programme en question a été conçu pour détourner ce signal. Le processus de pid 2243 apparaîtra toujours dans la liste des processus et il faudra lui envoyer un signal KILL :

$ kill -KILL 2243
$

qui comme on l'a vu précédemment ne peut être détourné ; le processus de pid 2243 est donc irrémédiablement arrêté.

Assurer le confort des autres - On considère ici que le fameux programme winword-2005 que tout le monde utilise sans vraiment savoir pourquoi, n'est pas en train de s'emballer, mais simplement prend un peu trop de ressources. La tâche effectuée est lourde, mais importante pour l'utilisateur qui décide donc d'interrompre le programme pour le reprendre plus tard : 

$ kill -STOP 2243
$

On peut constater que le programme interrompu est effectivement dans cet état en examinant le champ STATE :

$ ps -o pid,pcpu,pmem,state,cmd
PID %CPU %MEM S CMD
2177 0.0 2.1 S -bash
2243 0.0 25.3 T winword-2005
2244 0.0 1.7 R ps -o pid,pcpu,pmem,state,cmd
$

Ce champ est positionné à T qui indique que le processus de pid 2243 est interrompu.

L'utilisateur, soucieux d'achever son travail, pourra alors lancer la commande en fin de journée pour ne pas gêner ses collègues : 

$ kill -CONT 2243
$

qui indique au processus de pid 2243 de reprendre son exécution.

Le contrôle de tâches ou job control permet de manipuler les processus tournant sur un terminal donné. Sur chaque terminal, on distingue deux types de processus :

1. le processus en avant-plan, c'est celui qui peut utiliser le terminal comme canal de communication avec l'utilisateur par le biais du clavier ; on dit également qu'on « à la main » sur ce type de processus ;
2. les processus en arrière plan (ou tâche de fond) ; ceux-là peuvent utiliser le terminal comme canal de sortie (pour afficher des informations par exemple) mais ne peuvent lire les données que leur fournirait l'utilisateur.

Ce qui est écrit ci-dessus est le comportement qu'on rencontre généralement sur un terminal avec la plupart des applications. Il n'est par contre pas inutile de noter que selon qu'une application intercepte ou ignore les deux signaux particuliers TTOU et TTIN (respectivement écriture ou lecture d'un processus en arrière-plan), le comportement pourra être différent.

Les shells supportant le contrôle de tâches(41) offrent un certain nombre de commandes et de combinaisons de touches qui permettent entre autres :

• d'interrompre ou d'arrêter un programme ;
• de passer un programme en arrière ou en avant-plan ;
• de lister les processus en arrière-plan.

Nous vous proposons de passer en revue ces fonctionnalités en se plaçant dans le cadre d'un exemple simple : supposons que dans un terminal donné, un utilisateur lance l'éditeur Emacs :

$ emacs

Une fois Emacs lancé, l'utilisateur n'a plus la main sur le terminal(42), et tout caractère saisi reste en attente, jusqu'à la fin de l'exécution d'Emacs :

$ emacs
qdqsqmlskdjf
 <------------------------------------------- fin du progamme emacs
$ qdqsqmlskdjf
bash: qdqsqmlskdjf: command not found
$

Pour arrêter un programme en avant-plan, on peut utiliser la célèbre combinaison de touche (Ctrl-c) :

$ emacs
 <----------------------------------------------- Control + c
$

Ctrl-C envoie le signal INT au processus en avant-plan dans le terminal.

Pour passer Emacs (le programme de notre exemple) en arrière-plan, il faut procéder en deux temps : appuyer sur la touche puis la touche en même temps (on note souvent Ctrl-z)(43), ce qui a pour effet d'envoyer le signal STOP au programme s'exécutant en avant-plan sur le terminal.

$ emacs
 <---------------------------------------------------- Control + z
[1]+ Stopped emacs
$

Il faut ensuite passer le programme en tâche de fond grâce à la commande interne bg (background) :

$ bg
[1]+ emacs &
$

Le numéro entre crochet ([1]) est le numéro de la tâche dans le terminal courant.

On parle aussi de job. On peut également lancer directement une commande ou programme en tâche de fond, en postfixant la commande par le caractère & :

$ emacs&
[1] 1332
$

Ici le système attribue à Emacs le job [1], et le shell affiche sur le terminal le pid correspondant (1332).

La commande jobs permet d'obtenir une liste des tâches en arrière-plan, ou interrompues, sur le terminal. Par exemple :

$ xclock & xlogo & xbiff &
[1] 1346
[2] 1347
[3] 1348
$

lance trois programmes donnant lieu à la création d'une fenêtre graphique. On peut lister ces tâches :

$ jobs
[1] Running xclock &
[2]- Running xlogo &
[3]+ Running xbiff &
$

Il est possible de faire référence à une tâche par son numéro grâce à la notation %numéro_de_tâche. Ceci est valable pour les commandes bg et kill vues précédemment, mais aussi pour la commande permettant de passer une tâche en avant-plan : la commande fg (foreground). Ainsi par exemple pour passer xlogo en avant-plan :

$ fg %2
xlogo
 <----------------------- maintenant on n'a plus la main.