\typeout{+==============================================+}
\typeout{|============= GUIDE DE SURVIE ================|}
\typeout{+==============================================+}
\chapter{Petit guide de survie}
\label{chap-guide-survie}

\begin{epigraphname}{'Tain c'est pô convivial !}
     \verb+eval $(echo \+\\
     \verb/"3chA+2A96ADB+*+8157+7AE19A^395C304B"  |\/\\
     \verb/tr "1+2*3456789ABCDE^0" "a\ b\|efijlmnorsuz@.")/
\end{epigraphname}

%%      \verb+ echo \+\\

\begin{introchap}{La convivialité}
  \index{convivialité}d'un système \unix{}
  réside dans la souplesse et la puissance des outils dont on dispose
  pour dialoguer avec le système. Il s'agit certes d'une convivialité
  à laquelle peu d'utilisateurs sont habitués ; essentiellement parce
  qu'elle demande un investissement sur le plan de la documentation et
  de l'apprentissage.  Ce chapitre a donc pour but de présenter les
  fonctionnalités de base d'un système \unix{} sur le plan de son
  \emph{utilisation} (c.-à-d.  qu'il ne sera pas question ici
  d'administration d'un système). On verra donc dans un premier temps
  une présentation succincte de l'interface de base à savoir le
  \emph{shell}, suivront des présentations des concepts d'utilisateur,
  de système de fichiers, de processus. Le chapitre est clos par une
  explication rapide des services de base du système (impression,
  tâches planifiées, ...).
\end{introchap}


%===================================================================
%
%    SHELL
%
%===================================================================

%
% le shell unix
%
\section{Le shell}
\label{sec-shell}

Le \emph{shell}\index{shell} est une interface avec le système \unix.
Il offre à l'utilisateur l'interface de base avec le système
d'exploitation. L'étymologie du mot nous apprend qu'on peut l'imaginer
comme une \emph{coquille} englobant le noyau et ses composants. Le
shell est également un \emph{programme} qu'on appelle
\emph{interpréteur de commandes}. Ce programme tourne dans une fenêtre
ou sur une console en mode texte. Dans une fenêtre d'un environnement
graphique, il a l'allure de la figure~\vref{fig-unix-shell}.  On parle
\begin{figure}[htbp]
  \centering
  \includegraphics[width=.8\textwidth]{shell}
  \caption{Un shell dans une fenêtre}
  \label{fig-unix-shell}
\end{figure}
également de \emph{terminal} (ou d'émulateur de terminal) pour
désigner un écran ou une fenêtre dans laquelle est exécuté le shell.
Il existe plusieurs shells dans le monde \unix, les plus courants sont
:
\begin{itemize}
\item \texttt{sh} : fait initialement référence au premier shell
  d'\unix{} conçu par Steve \emph{Bourne}, utilisé notamment pour les
  scripts système ;
\item \texttt{ksh}  : le Korn shell ;
\item \texttt{csh}  : le C shell (dont la syntaxe rappelle vaguement
  celle du C pour ce qui est des structures de contrôle) ;
\item \texttt{bash} : le shell de \gnu{}\footnote{Bash signifie «
    Bourne Again Shell » : un jeu de mot avec la construction anglaise
    « born again » qui signifie renaissance.} qui est, comme mentionné
  dans la page de manuel, « trop gros et trop lent ». C'est malgré
  tout celui sur lequel nous nous attarderons dans ce manuel ;
\item \texttt{tcsh} : le Tenex C shell contient tout ce qu'apporte
  \texttt{csh} avec des fonctionnalités supplémentaires notamment une
  édition plus aisée de la ligne de commande ;
\item \texttt{zsh} le Zorn shell contenant un langage de programmation
  plus évolué que \texttt{bash} et des fonctionnalités de
  complétions avancées\footnote{Votre serviteur n'a aucune expérience
    dans ce shell et vous prie de bien vouloir excuser par avance
    l'absence de script \texttt{zsh} dans ce manuel...} ;
\item ...
\end{itemize}

\index{shell!interactif}
Le shell est utilisé le plus souvent de manière interactive, pour
passer des \emph{commandes} au système. Pour signifier que le shell
est prêt à recevoir ces commandes, il affiche un \emph{prompt}. Ce
prompt peut contenir un nombre variable d'informations selon la
\voir{sec-conf-shell}{configuration}, et nous y ferons référence de la
manière suivante :
\index{shell!prompt}
\index{invite|see{prompt}}
\index{prompt}
\begin{flushleft}
\shellprompt{}
\end{flushleft}
On peut illustrer le fonctionnement d'un shell, avec l'algorithme
suivant :
\begin{algo}[noendkeyword]
  \FORGEN{toujours}
  \STATE{Afficher le prompt et attendre une commande}
  \STATE{Vérifier sa syntaxe}
  \IF{la syntaxe est correcte}
  \STATE{exécuter la commande}
  \ELSE
  \STATE{afficher un message d'erreur}
  \ENDIF
  \ENDFOR
\end{algo}
Notons enfin que si nous présentons ici le shell dans son utilisation
interactive, il est également utilisé sous forme de
\voir[][20pt]{sec-dev-shell}{\emph{scripts}}, dans ce cas les commandes
passées au système peuvent être enregistrées dans des fichiers qui
peuvent ensuite être exécutés. En cela le langage de commande peut
être utilisé comme un langage interprété.

\subsection{Qu'est-ce qu'une commande ?}
\index{commande}
Exécuter ou lancer une  commande, consiste de manière synoptique en ceci :
\begin{flushleft}
\comarg{nom-commande} \comarg{options} \comarg[1]{arg} \comarg[2]{arg} ... 
\comarg[n]{arg}
\toucheEntree{}\\
...\\
résultat de la commande sur le terminal\\
...
\end{flushleft}

\comarg{nom-commande} est le nom de la commande à exécuter ; cette
dernière peut accepter un certain nombre d'options dont la syntaxe
est en général :
\begin{itemize}
\item \texttt{-}\comarg{option} par exemple \texttt{-a}, ou 
\item \texttt{{-}-}\comarg{option} par exemple \texttt{{-}-verbose}.
\end{itemize}
Un exemple :
\begin{shellcom}
  ¢usercom«ls -l guide-unix.tex» «¢normalfont¢touche«Entrée»»
  -rw-r--r--  1 vincent users   2159 Nov  7 13:28 guide-unix.tex
\end{shellcom}
Celui-ci exécute la commande \com{ls}\footnote{<< Équivalent >> du
  \texttt{dir} de MSDOS, pour afficher les propriétés d'un
fichier ou le contenu d'un répertoire.} avec l'option~\texttt{l} et l'argument
\texttt{guide-unix.tex}. Le résultat de la commande \texttt{ls} est expliqué
à la section~\ref{sec-filesystem}.
\begin{note}
  On peut noter que commande, options et arguments\footnote{Du point
    de vue du shell une option est un argument comme un autre ayant la
    particularité de commencer par le caractère \texttt{-}.} sont séparés
  par des espaces.  Il faut comprendre que l'analyse de la ligne de
  commande par le shell est effectuée en séparant dans un premier
  temps les éléments (commande, options et arguments) par des espaces.
  Au cas où un nom de fichier contiendrait un espace, il faudra
  indiquer au shell que le nom est à considérer comme un seul élément
  en procédant comme indiqué à la section~\vref{sec-unix-espace-noms}.
\end{note}


\subsubsection{Commandes internes et commandes externes}
\index{commande!interne}
\index{commande!externe}
Une commande peut être \emph{interne} (\emph{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 :
\begin{algo}[noendkeyword]
  \FORGEN{toujours}
  \STATE{Afficher le prompt et attendre une commande}
  \STATE{Vérifier sa syntaxe}
  \IF{la syntaxe est correcte}
    \IF{c'est une commande interne}
    \STATE{l'exécuter}
    \ELSE
    \STATE{chercher le fichier exécutable correspondant}
    \STATE{l'exécuter}
    \ENDIF
  \ELSE
    \STATE{afficher un message d'erreur}
    \ENDIF
  \ENDFOR
\end{algo}
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
\voir{sec-unix-env}{variable d'environnement} nommée~\envvar{PATH}.
Dans le shell utilisé par votre serviteur :
\framaserre{\baselineskip}%
\begin{shellcom}
  ¢usercom«type cat»
  cat is /bin/cat
  ¢usercom«type echo»
  echo is a shell builtin
\end{shellcom}
La commande \com{type} nous informe que \com{echo} est une commande
interne et que la commande \com{cat} ne l'est pas (\emph{i.e.} est un
programme dans le répertoire \texttt{/bin}). \com{type} est une
commande interne du shell \texttt{bash}. L'équivalent pour la famille
des C-shells est \com{which}.

\subsubsection{Messages d'erreurs}
\index{messages!d'erreur}

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
\emph{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 :
\begin{itemize}
\item la commande n'existe pas :
  \begin{shellcom}
    ¢usercom«youpla»
    bash: youpla: command not found
  \end{shellcom}
\item l'argument  spécifié ne correspond à aucun fichier :
  \begin{shellcom}
    ¢usercom«cp mlkj essai.tex»
    cp: mlkj: No such file or directory
  \end{shellcom}
\item l'utilisateur ne possède pas les droits suffisants :
  \begin{shellcom}
    ¢usercom«cp g.dat /»
    cp: cannot create file `/g.dat': Permission denied
  \end{shellcom}
\item la commande n'est pas utilisée avec les bonnes options :
  \begin{shellcom}
    ¢usercom«cat -l fichier.tmp»
    cat: invalid option -- l
    Try `cat --help' for more information.
  \end{shellcom}
\end{itemize}
À 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.


\subsubsection{Composer les commandes}
\index{commande!composition}
\index{;}
On peut composer deux ou plusieurs commandes à l'aide du caractère~«;»
:
\begin{shellcom}
  ¢usercom«ls guide-unix.tex ; echo bonjour»
  guide-unix.tex
  bonjour
\end{shellcom}
Notons au passage que la commande \com{echo} affiche à l'écran la
chaîne de caractère qui suit.  Il existe deux autres opérateurs
permettant de combiner deux commandes :
\index{;@\texttt{\&\&}}
\index{;@\texttt{"|"|}}
\begin{itemize}
\item l'opérateur \texttt{\&\&}
  \begin{flushleft}
    \comarg[1]{commande} \verb+&&+ \comarg[2]{commande}
  \end{flushleft}
  exécute \comarg[2]{commande} si \comarg[1]{commande} s'exécute sans
  erreur ;
\item l'opérateur \texttt{||}
  \begin{flushleft}
    \comarg[1]{commande} \verb+||+ \comarg[2]{commande}
  \end{flushleft}
  exécute \comarg[2]{commande} si \comarg[1]{commande} renvoie une erreur.
\end{itemize}
\begin{attention}
  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
  \S~\vref{sec-developper-com-renv-val}).
\end{attention}

\subsection{« Convivialité »  et ergonomie}
\label{sec-conv-ergo}


\`A la fin des années 80, les éditeurs de logiciels axaient leur
publicité sur la « convivialité » de leurs produits. Un programme
était alors dit « convivial » lorsqu'il présentait à l'utilisateur
moult menus, boîtes de dialogue et autres icônes. Il s'avère cependant
que pour une utilisation intensive d'un logiciel, la dite « convivialité »
devient plutôt une contrainte et l'utilisateur cherche rapidement les
raccourcis clavier pour une utilisation plus confortable.

D'autre part, si l'on songe que le langage de commande est un
\emph{langage} en tant que tel, il permet à l'utilisateur d'exprimer
(tout) ce qu'il veut et cela de manière très souple. Ceci est à
comparer avec un logiciel qui propose des fonctionnalités sous forme de
menus ou de boîtes de dialogue, qui laissent finalement à
l'utilisateur une marge de man\oe{}uvre souvent restreinte.

C'est pourquoi la vraie question n'est pas celle de la
pseudo-convivialité ---~qui est plus un argument de vente auprès du
grand public~--- mais celle de l'\emph{ergonomie} d'un logiciel. Est-il
possible d'exprimer de manière concise et rapide la tâche que l'on
désire faire effectuer à la machine ? Le shell est un programme
\emph{ergonomique} et l'utilisateur qui a fait l'effort de
l'\emph{apprentissage} du langage de commande le constate très
vite\footnote{On préfère rapidement presser quelques touches de
  clavier plutôt que de se lancer dans une vingtaine de « clic-clic »
  sur des demi-douzaines de fenêtres empilées les unes sur les
  autres.}.
\begin{attention}
  Ah oui : l'utilisation du langage de commande d'\unix{} repose sur
  l'utilisation intensive du clavier. Il est donc important de se
  familiariser avec ce périphérique voire d'apprendre via des méthodes
  adéquates à l'utiliser de manière optimale.
\end{attention}

Dans la mesure où le pressage de touches  de clavier est l'activité
première de l'utilisateur \unix{}, quelques « aménagements » ont été
mis en place :
\begin{itemize}
\item \emph{l'historique} des commandes : les touches
  \toucheUp{} et \toucheDown{} permettent de rappeler
  les commandes précédemment tapées pour éventuellement les modifier
  et les relancer ;
\item la \emph{complétion} des commandes : la touche \toucheTab{}
  (tabulation) permet de compléter les noms de commandes, les noms de
  fichiers et de répertoires à partir des premiers caractères de leur
  nom. À utiliser intensivement !
\end{itemize}
\begin{gnuposix}
  Si un jour vous vous connectez sur une « vieille » machine \unix{}
  et/ou que vous avez à dialoguer avec un « vieux » shell ne
  disposant ni de la complétion ni du rappel des commandes, ce jour-là
  vous comprendrez que \texttt{bash} (ou le shell que vous avez
  l'habitude d'utiliser), malgré son caractère apparemment spartiate,
  est un programme vraiment \emph{moderne}...
\end{gnuposix}

\subsection{Rudiments sur les variables d'environnement}
\label{sec-unix-env}
\index{variable!d'environnement}
\index{environnement!variable d'}
Lorsqu'un shell est exécuté par le système, un certain nombre de
variables dites d'\emph{environnement} sont instanciées. Ces variables
permettent à l'utilisateur et aux programmes lancés par le shell
d'obtenir plusieurs informations sur le système, la machine et
l'utilisateur, entre autres. La commande \com{env} affiche à
l'écran toutes les variables d'environnement pour le shell. En voici
un extrait :
\begin{shellcom}
  ¢usercom«env»
  MAIL=/var/spool/mail/vincent
  HOSTTYPE=i386
  PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
  HOME=/home/vincent
  SHELL=/bin/bash
  USER=vincent
  OSTYPE=Linux
\end{shellcom}
On comprend aisément que ces variables d'environnement définissent
respectivement, le fichier réceptacle du courrier, le type de la
machine, la liste des répertoires\footnote{Voir à ce sujet les
  paragraphes~\vref{sec-conf-shell} et~\vref{sec-developper-exe} qui
  traitent de la variable \envvar{PATH}.}  où le shell va chercher les
exécutables (pour les commandes qui ne sont pas internes), le
répertoire privé de l'utilisateur, le nom de l'utilisateur et le type
de système d'exploitation.  En préfixant le nom d'une variable par un
dollar (\texttt{\$}), on accède à la valeur de cette variable. Ainsi :
\begin{shellcom}
  ¢usercom«echo $SHELL»
  /bin/bash
\end{shellcom}
%$
est un moyen de connaître le shell qui est associé à votre utilisateur
dans la base de données du système.
\begin{attention}
  En réalité toutes les variables d'un shell ne sont pas des variables
  d'environnement, dans le sens où toutes les commandes n'y ont pas
  nécessairement accès. Par contre n'importe quelle variable peut
  devenir une variable d'environnement à l'aide de la commande interne
  \com{export}.
\end{attention}

\subsection{Caractères  spéciaux}
\label{sec-unix-car}
\index{caractères!spéciaux} \index{;@\texttt{\$}} \index{;@\texttt{/}}
\index{;@\texttt{\~{}}} \index{;@\texttt{\&}} \index{;@\texttt{*}}
\index{;@\texttt{?}}  \index{;@\texttt{"|}} \index{;@\texttt{>}}
\index{;@\texttt{<}} \index{;@\texttt{;}} \index{;@\texttt{\#}} Un
certain nombre de caractères sont dits spéciaux, car ils sont
interprétés d'une manière particulière par le shell. Le plus connu de
ces caractères est sans doute celui qui sépare les répertoires dans un
chemin\footnote{Le caractère \texttt{/} n'est en réalité spécial que
  dans le traitement des références sur les fichiers ou répertoires, et
  non pour le shell lui-même.}. Sous \unix, c'est le
\emph{slash}~(\texttt{/}). Par exemple :
\verb+/home/users/hendrix/wahwah.dat+.  Voici une liste des caractères
spéciaux les plus communs du shell :
\begin{itemize}
\item \verb+$+ permet le mécanisme d'expansion et donc permet de
  faire référence à la valeur de la variable nommée après, mais aussi de
  \voir{sec-shell-var-arithmetique}{faire des calculs} ou d'exécuter
  une autre commande (\S~\vref{sec-toolbox-substitution-commande})
  ; %$
\item \verb+~+  remplace le \voir{sec-filesystem}{répertoire privé} de
    l'utilisateur ;
\item \verb+&+  lance une commande en \voir{sec-processus}{arrière-plan} ;
\item \verb+*+  remplace toute chaîne de caractères ;
\item \verb+?+  remplace tout caractère (voir la section suivante
  pour ces deux caractères) ;
\item \verb+|+  pour créer un \voir{sec-pipes}{tube} ;
\item \verb+>+ et  \verb+<+  pour les
  \voir{sec-redirection}{redirections} ;
\item \verb+;+ est le séparateur de commandes ;
\item \verb+#+ est le caractère utilisé pour les 
  \voir{sec-shell-comment}{commentaires} ;
\item ...
\end{itemize}


\index{fichier!nom}
\index{nom!de fichier}
Il est bien entendu que puisque ces caractères ont un rôle
particulier, il est peu recommandé de les utiliser dans les noms de
fichiers, au risque de compliquer le dialogue avec le shell
(voir le paragraphe sur les mécanismes d'expansion
page~\pageref{sec-unix-expansion}).

\subsection{Espaces dans les noms  de fichiers}
\label{sec-unix-espace-noms}
\index{caractères!espace}
\index{fichier!avec espace}
\index{espace (nom de fichier)}

Le caractère espace n'est pas un caractère spécial pour le shell,
cependant son utilisation dans les noms de fichiers modifie légèrement
la manipulation des commandes. Imaginons par exemple que l'on veuille
effacer un fichier nommé « zeuhl wortz.txt », la commande « naïve »
suivante échouera :
\begin{shellcom}
  ¢usercom«rm zeuhl wortz.txt»
  rm: cannot remove `zeuhl': No such file or directory
  rm: cannot remove `wortz.txt': No such file or directory
\end{shellcom}
car le shell tente d'effacer deux fichiers au lieu d'un seul puisqu'il
délimite les mots à l'aide du caractère espace. Pour expliquer au
môssieur que « zeuhl wortz.txt » désigne un seul fichier, il est
nécessaire « d'échapper » le caractère espace :
\begin{shellcom}[noendprompt]
  ¢usercom«rm zeuhl\ wortz.txt»
\end{shellcom}
ou d'indiquer explicitement que le nom est composé d'un seul « mot »
en l'entourant de guillemets (\verb+"+) ou d'apostrophes (\verb+'+) :
\begin{shellcom}[noendprompt]
  ¢usercom«rm "zeuhl wortz.txt"»
\end{shellcom}
ou :
\begin{shellcom}[noendprompt]
  ¢usercom«rm 'zeuhl wortz.txt'»
\end{shellcom}

\subsection{Caractères génériques}
\label{sec-unix-jokers}
\index{caractères!génériques} \index{wildcard@\anglais{wildcard}}
\index{joker@\anglais{joker}} Il existe au moins deux moyens
d'utiliser les caractères génériques (parfois dits \emph{wildcards} ou
\emph{jokers} en anglais). Voici deux exemples en reprenant la
commande \com{ls} :
\begin{shellcom}
  ¢usercom«ls guide-unix*»
  guide-unix.aux  guide-unix.dvi  guide-unix.log  guide-unix.tex
\end{shellcom}
liste tous les fichiers du répertoire courant commençant par
\texttt{guide-unix}. Et :
\begin{shellcom}
  ¢usercom«ls guide-unix.??x»
  guide-unix.aux  guide-unix.tex
\end{shellcom}
liste les fichiers dont l'extension est composée de deux caractères
quels qu'ils soient et terminée par un \texttt{x}. Une des étapes
d'interprétation de ces commandes par le shell consiste à remplacer
les jokers par leur valeur ; ainsi, la dernière commande équivaut à :
\begin{shellcom}[noendprompt]
  ¢usercom«ls guide-unix.aux  guide-unix.tex»
\end{shellcom}
\index{expansion} Ce mécanisme de remplacement des jokers par une
valeur se nomme en jargon (anglais) \unix{} : \anglais{pathname
  expansion} ou \anglais{globbing}.
\begin{note}
  Notons ici que l'on peut bien évidemment composer les
  caractères~«\texttt{*}» et~«\texttt{?}» et qu'il existe d'autres
  formes de joker, comme par exemple la séquence «\texttt{[...]}»  que
  nous ne présentons pas ici, et bien d'autres qui dépendent du shell
  utilisé.  Il est pour l'instant utile de noter que ces caractères,
  même s'ils se rapprochent des expressions régulières présentées au
  paragraphe~\vref{sec-regexp}, ne doivent pas être confondues avec
  icelles...  \index{expression régulière}
\end{note}


%===================================================================
%
%    UTILISATEURS
%
%===================================================================

\section{Utilisateurs}
\index{utilisateur!logique}
\index{utilisateur!identificateur}
\index{identificateur!d'utilisateur}
\index{uid}
\index{répertoire!utilisateur}
\index{utilisateur!répertoire}
\index{shell!utilisateur}
\index{groupe!utilisateur}
\unix{} a été conçu comme un système multi-utilisateur, ce qui
signifie que chaque utilisateur est identifié sur le système par un
utilisateur \emph{logique} auquel correspond un certain nombre de
droits ou privilèges. À un utilisateur sont, entre autres, associés :
\begin{itemize}
\item un numéro ou identificateur : l'uid (pour \anglais{user
    identifier}) ;
\item une chaîne de caractères se rapprochant généralement de l'état
  civil, appelée \emph{login name} ;
\item le groupe auquel l'utilisateur appartient, et éventuellement
  d'autres grou\-pes d'utilisateurs supplémentaires ;
\item un répertoire privé (\anglais{home directory}) ;
\item un shell qui sera utilisé par défaut après la connexion.
\end{itemize}
On peut savoir sous quel utilisateur logique on est connecté grâce à
la commande \com{whoami} :
\begin{shellcom}
  ¢usercom«whoami»
  djobi
\end{shellcom}
En plus de son nom, un utilisateur est identifié en interne par son
\emph{uid} ou \anglais{user identifier}. D'autre part un utilisateur
appartient à un ou plusieurs groupes d'utilisateurs. Chacun de ces
groupes est également identifié par son nom et un numéro appelé
\emph{gid} ou \anglais{group identifier}. On peut connaître l'identité
d'un utilisateur par la commande \com{id} :
\index{identificateur!de groupe}
\index{groupe}
\begin{shellcom}
  ¢usercom«id lozano»
  uid=208(lozano) gid=200(equipe) groups=200(equipe),300(image)
\end{shellcom}
l'utilisateur \texttt{lozano} appartient aux groupes \texttt{equipe} et
\texttt{image}. C'est généralement l'administrateur du système qui
décide de regrouper les utilisateurs dans des groupes qui reflètent la
structure des personnes physiques qui utilisent les ressources
informatiques. Chacun de ces groupes se voit généralement attribuer
un ensemble de privilèges qui lui est propre.

Pour terminer avec les utilisateurs, sachez qu'en général un
utilisateur ne peut intervenir que sur un nombre limité d'éléments du
système d'exploitation. Il peut : 
\index{droits!utilisateur}
\begin{itemize}
\index{répertoire!home}
\index{;@\texttt{\~{}}}
\item créer des fichiers dans une zone particulière appelée \emph{home
    directory} ou répertoire privé ou tout simplement \emph{home}. En
  fonction de la configuration du système les utilisateurs pourront
  bien sûr écrire dans d'autres zones. Le répertoire privé est désigné
  dans le shell par «\texttt{\~}» :
  \begin{shellcom}
    ¢usercom«echo ~»
    /home/utilisateurs/djobi
  \end{shellcom}
\item influer sur le cours des programmes qu'il a lui-même lancé ;
\item autoriser ou interdire la lecture ou l'écriture des fichiers
  qu'il a créés.
\end{itemize}
Il ne peut pas :
\begin{itemize}
\item effacer les fichiers d'un autre utilisateur sauf si ce dernier
  l'y autorise (en positionnant les droits corrects sur le répertoire
  contenant le fichier en question) ;
\item interrompre des programmes lancés par un autre utilisateur (là
  aussi, sauf si il y est autorisé par l'utilisateur en question) ;
\item créer des fichiers « n'importe où. »
\end{itemize}
Par conséquent une machine gérée par un système d'exploitation de type
\unix{} ne peut pas être compromise \emph{par hasard ou maladresse}
par un utilisateur. Puisqu'il faut bien (maintenance, mise à jour,
etc.) que certains fichiers soient modifiés, il existe au moins un
utilisateur possédant tous les privilèges sur le système :
l'utilisateur dont \index{utilisateur!root} \index{root!utilisateur}
l'uid est $0$ portant généralement le nom de \texttt{root} (car son
répertoire racine était souvent installé à la racine (\emph{root} en
anglais) du système de fichier). Cet utilisateur a la possibilité et
le droit d'arrêter le système, d'effacer tous les fichiers (!), de
créer des utilisateurs, et bien d'autres choses qui constituent ce que
l'on nomme communément \emph{l'administration système.} Dans une
structure où le nombre de machines à administrer est conséquent, il se
cache plusieurs personnes physiques derrière cet uid $0$.

%=====================================================================
%
%       LE SYSTEME DE FICHIERs
%
%=====================================================================-

\section{Le système de fichiers}
\label{sec-filesystem}
\index{système de fichier} \index{fichier!système de} Le système de
fichiers d'\unix{} est une vaste arborescence dont les n\oe{}uds sont
des répertoires et les feuilles des fichiers. Le terme de fichier
s'entend ici dans un sens très large, puisque sous \unix, un fichier
peut contenir des données, mais peut aussi être un lien sur un autre
fichier, un moyen d'accès à un périphérique (mémoire, écran, disque dur, ...) ou
un canal de communication entre processus. Pour embrouiller un peu
plus le tout, les répertoires sont eux aussi des fichiers.  Nous nous
intéresserons ici aux fichiers normaux (\emph{regular} en anglais),
c'est-à-dire ceux qui contiennent des données ou sont des exécutables,
ainsi qu'aux liens et aux répertoires.

\subsection{Référencement des fichiers et des répertoires}
\label{sec-sys-ref-fichiers}

Pour manipuler un fichier ou un répertoire d'un système de fichiers,
l'utilisateur a besoin de les \emph{nommer}, en d'autres termes il a
besoin de pouvoir \emph{désigner} un fichier particulier de
l'arborescence des fichiers et ceci de manière univoque. Il existe
pour ce faire, deux moyens : les \emph{références absolues} et les
\emph{références relatives}, toutes deux décrites ci-après.

\subsubsection{Référence absolue}

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~\texttt{bidule.dat} et \texttt{truc.txt} de
l'arborescence donnée en exemple à la figure~\vref{fig-arbo-fic} par :
\begin{verbatim}
/users/bidule.dat
/home/eleves/truc.txt
\end{verbatim}
Le caractère \verb+/+ joue deux rôles :
\begin{itemize}
\item d'une part il désigne le \emph{répertoire racine} (\emph{root
    directory} en anglais) ;
\item d'autre part il fait usage de \emph{séparateur} de répertoires
  dans l'écriture des références de fichiers et répertoires.
\end{itemize}
\begin{figure}[ht]
  \begin{center}
    \includegraphics[width=.35\textwidth]{reference}
    \caption{Une arborescence de fichiers pour l'exemple}
    \label{fig-arbo-fic}
  \end{center}
\end{figure}
Pour désigner un répertoire on utilisera le même principe,
ainsi les répertoires \texttt{eleves} et \texttt{users} ont comme
référence absolue :
\begin{verbatim}
/home/eleves
/users
\end{verbatim}

\subsubsection{Référence relative}

Il est souvent utile de désigner les fichiers et répertoires grâce à
une \emph{référence relative}.  Dans ce cas on référencera un fichier
ou un répertoire \emph{relativement} à un répertoire de base. Par
exemple :
\begin{itemize}
\item si \verb+/users+ est le répertoire de base, alors il est
  possible de référencer les fichiers~\texttt{bidule.dat}
  et~\texttt{truc.txt} comme suit :
\begin{verbatim}
./bidule.dat
../home/eleves/truc.txt
\end{verbatim}
\item si \verb+/home+ est le répertoire de base, alors on peut les
  référencer comme suit :
\begin{verbatim}
../users/bidule.dat
./eleves/truc.txt
\end{verbatim}
\end{itemize}
Deux répertoires particuliers existent dans chaque répertoire :
\begin{itemize}
\item le répertoire \verb+.+ qui désigne le répertoire courant ;
\item le répertoire \verb+..+ qui désigne le répertoire parent.
\end{itemize}

On pourra noter que l'écriture \verb+./bidule.dat+ est redondante et
peut être abrégée en \verb+bidule.dat+. Enfin, le répertoire de
référence dont il a été question est souvent le répertoire dit
\emph{courant} ou répertoire de travail (\emph{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.
\begin{note}
  Le répertoire « \verb+.+ » a également une utilisation importante
  lorsqu'on veut \voir{sec-developper-exe}{exécuter} 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 \envvar{PATH}.
\end{note}

\begin{note}
  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...
\end{note}


\subsection{Arborescence}
\label{sec-unix-arborescence}
\index{arborescence}

Pour comprendre le fonctionnement de l'arborescence d'un système de
fichiers \unix, supposons que la machine que nous utilisons soit
composée des deux disques durs et du disque amovible de la
figure~\ref{fig-disques}. 
\begin{figure}
\begin{center}
\subfloat[Partionnement des disques]{%
  \includegraphics[width=\ifframabookversion.85\textwidth\else\textwidth\fi]{%
    disques}%
  \label{fig-arborescence}}\\
\subfloat[Montages]{%
  \includegraphics[width=\textwidth]{arborescence}%
  \label{fig-disques}}
\end{center}
\caption{Exemple de partitionnements et montages correspondant.}
\end{figure}
Sous \unix, une telle configuration de disques peut se présenter sous
la forme de la figure~\ref{fig-arborescence}.
\index{disques!physiques}%
\index{disques!logiques}%
\index{partition}%
\index{montage de partition}%
\index{partition!montage}%
En jargon \unix, on dit que chaque partition est << montée sur >> (de
la commande \com{mount}) ou << greffée sur >> un répertoire
particulier. Dans notre exemple :
\begin{itemize}
\item la partition 1 du disque dur 1 est montée sur la racine (\texttt{/}) ;
\item la partition 2 du disque dur 1 est montée sur \texttt{/export} ;
\item la partition 1 du disque dur 2 est montée sur \texttt{/usr/local} ;
\item la partition 1 du disque amovible  est montée sur \texttt{/mnt}.
\end{itemize}
\index{arborescence!racine}
\index{racine!de l'arborescence}
Ce qu'il faut retenir, c'est que quelle que soit la configuration des
disques sous-jacente au système, il n'y a toujours qu'une seule racine
(répertoire~\texttt{/}) et donc une seule arborescence.  Chaque
partition est greffée en un point particulier
de l'arborescence globale ---~on parle également de \emph{filesystem}
pour désigner la sous-arborescence greffée\footnote{Rappelons que sous
  d'autres systèmes (la famille des fenêtres pour ne pas les nommer)
  on aurait eu dans notre étude de cas, les disques logiques
  \texttt{C:} et \texttt{D:} pour le premier disque dur, \texttt{E:}
  pour le deuxième disque dur et sans doute \texttt{F:} ou \texttt{A:}
  pour le support amovible ; ainsi qu'une arborescence propre associée
  à chacune de ces lettres. Rappelons en outre que ces lettres sont
  une séquelle du tristement célèbre Disk Operating System.}.
\begin{note}
  Notons également que différents mécanismes existent sous \unix{}
  pour greffer des systèmes de fichiers \emph{distants} c.-à-d.
  résidant sur une machine accessible via le réseau. Le plus utilisé
  actuellement est le système NFS (\emph{network filesystem})
  introduit par Sun.\index{NFS}
\end{note}

\index{inode}
\index{index node}
Chaque n\oe{}ud de l'arborescence est identifié en interne de manière
univoque par deux nombres :
\begin{enumerate}
\item le numéro de la partition ;
\item le numéro du n\oe ud appelée \emph{inode} ou \emph{index node}.
\end{enumerate}
En d'autres termes, chaque fichier possède un numéro qui est unique
sur la partition où il réside.  On peut visualiser l'inode d'un
fichier grâce à l'option \texttt{i} de la commande \com{ls} :
\begin{shellcom}
  ¢usercom«ls -i *.tex»
  ¢rwx«65444»  guide-unix.tex
\end{shellcom}
ici, 65444 est l'inode du fichier \texttt{guide-unix.tex}. Sur le
système où est tapé ce document, les fichiers suivants ont le même
inode :
\begin{shellcom}
  ¢usercom«ls -i /lib/modules/2.2.12-20/misc/aedsp16.o»
       19 /lib/modules/2.2.12-20/misc/aedsp16.o
  ¢usercom«ls -i /usr/X11R6/man/man1/identify.1»
       19 /usr/X11R6/man/man1/identify.1
\end{shellcom}
ce qui s'explique par le fait que le répertoire \texttt{lib}
appartient à la partition \texttt{/} alors que \texttt{X11R6}
appartient à une partition différente montée sur le répertoire
\texttt{/usr}. Pour examiner les partitions de notre système, on peut
utiliser la commande \com{df} avec l'option \texttt{-h} (pour
\emph{human readable}) :
\begin{shellcom}
  ¢usercom«df -h»
  Filesystem            Size  Used Avail Use% Mounted on
  /dev/hda1             194M   42M  142M  23% /
  /dev/hda7             1.1G  566M  508M  53% /home
  /dev/hda5             791M  606M  144M  81% /usr
  /dev/sda4              96M   95M  584k  99% /mnt/zip
  /dev/hdb              643M  643M     0 100% /mnt/cdrom
\end{shellcom}
Cette commande affiche donc pour chaque partition le fichier
\emph{device} associé (sous la forme \texttt{/dev/xxx}) sa taille
respective ainsi que son taux d'occupation.  \index{partition!taux
  d'occupation} Les informations indiquant où doit être montée
chacune des partitions sont généralement stockées dans un fichier
nommé \texttt{/etc/fstab}.
\begin{gnuposix}
  L'option \texttt{-h} est une option de la version \gnu{} de la
  commande \com{df}. Votre sarcastique serviteur vous invitera donc à
  méditer sur ces programmes censés produire des résultats « lisibles
  par un être humain ». Mais ne vous méprenez pas, les systèmes
  \unix{} dont la commande \com{df} ne dispose pas de l'option
  \texttt{-h} sont quand même destinés aux humains...
\end{gnuposix}


\subsection{Privilèges}
\label{sec-unix-privileges}

\index{fichier!droits}
\index{privilèges|see{droits}}
\index{droits!fichier}
Il faut savoir que sous \unix, on associe à chaque fichier trois types
de propriétaires :
\begin{itemize}
\item l'utilisateur propriétaire ;
\item le groupe propriétaire ;
\item les autres utilisateurs.
\end{itemize}
\begin{nota}
  La norme POSIX apporte une extension à ce principe connue sous le
  nom \anglais{acces control list} (\voir{sec-unix-acl}{ACL}),
  permettant de recourir si nécessaire à un réglage plus fin que les
  trois entités ci-dessus. Cette extension est présentée au
  paragraphe~\vref{sec-unix-acl}.
\end{nota}
\index{fichier!attributs}
Chaque fichier possède un certain nombre d'attributs. Un sous-ensemble
de ces attributs a trait aux \emph{privilèges} ou \emph{droits}
qu'ont les utilisateurs lors de l'accès à un fichier donné. Il y a
trois types de privilèges :
\begin{enumerate}
\item le droit de lire (read) signalé par la lettre \texttt{r} ;
\item le droit d'écrire (write) signalé par la lettre \texttt{w} ;
\item le droit d'exécuter (execute) signalé par la lettre \texttt{x}.
\end{enumerate}
Ces trois types de droits associés aux trois types de propriétaires
forment un ensemble d'informations associées à chaque fichier ; ensemble
que l'on peut examiner grâce à la commande \com{ls} :
\index{droits!bloc}
\ifpdf
\vspace*{-10pt}%% !!!!!!!!!!!!!!! la truande
\begin{flushleft}
  \includegraphics{blocdroit1}
\end{flushleft}
\else
\input{blocdroit1}
\fi
\index{lien}
Nous verrons au paragraphe~\vref{sec-liens} la signification du terme
« lien » sur un fichier. Examinons d'un peu plus près le bloc des droits :
\ifpdf
\begin{flushleft}
  \includegraphics{blocdroit2}
\end{flushleft}
\else
\input{blocdroit2}
\fi
Autre exemple :
\begin{shellcom}
  ¢usercom«ls -l /usr/bin/env»
  -rwxr-xr-x   1 root  root   6852 Aug 18 04:31 /usr/bin/env
\end{shellcom}
Le fichier \verb+/usr/bin/env+ appartient à l'utilisateur
\texttt{root} et au groupe \texttt{root}. Seul l'utilisateur
\texttt{root} peut le modifier et tout le monde peut l'exécuter y
compris les membres du groupe \texttt{root} :
\begin{itemize} 
\item \verb+rwx+ : droits du propriétaire (\texttt{r}ead,
\texttt{w}rite, e\texttt{x}écutable) ;
\item \verb+r-x+ : droits du groupe (\texttt{r}ead, e\texttt{x}ecutable) ;
\item \verb+r-x+ : droits des autres (\texttt{r}ead, e\texttt{x}ecutable).
\end{itemize}
\begin{attention}
  Pour être plus précis, on peut dire que le fichier
  \verb+/usr/bin/env+ appartient à l'utilisateur dont l'uid est~0 et
  que la commande \com{ls} affiche le premier nom correspondant à cet
  uid. Tous les autres utilisateurs ayant le même uid sont également
  en mesure de le modifier.
\end{attention}
Un dernier exemple :
\begin{shellcom}
  ¢usercom«ls -l ~/»
  drwxr-xr-x   3 vincent  users        4096 Nov  7 12:48 LaTeX
  drwxr-xr-x   2 vincent  users        4096 Nov  7 14:40 bin
\end{shellcom}
Cette commande liste le répertoire privé de l'utilisateur (caractère
\texttt{\~}) et affiche ici les droits des deux répertoires qui y
résident :
\begin{itemize} 
\item \verb+d+ : le fichier est un répertoire ;
\item \verb+rwx+ : droits du propriétaire (\texttt{r}ead,
\texttt{w}rite, e\texttt{x}écutable) ;
\item \verb+r-x+ : droits du groupe (\texttt{r}ead et e\texttt{x}écutable) ;
\item \verb+r-x+ : droits des autres (\texttt{r}ead et e\texttt{x}écutable) ; 
\item les nombres 3 et 2 indiquent le nombre de sous-répertoires
contenus dans \texttt{LaTeX} et \texttt{bin} respectivement.
\end{itemize}
\index{répertoire}
\begin{attention}
  Il faut noter ici une particularité du système \unix{} : un
  répertoire doit être exécutable pour pouvoir y pénétrer, on parle
  alors de \anglais{search permission} en anglais. Dans
  l'exemple ci-dessus, tout le monde y compris les membres du groupe
  \texttt{users} a le droit d'accéder aux répertoires \texttt{LaTeX}
  et \texttt{bin}.
\end{attention}

\subsection{Parcourir l'arborescence}
\label{sec-parcourir}

Pour connaître le répertoire courant (\emph{i.e.} celui où on se
trouve au moment où on tape la commande) on peut taper la commande
\com{pwd} (\anglais{print working directory}). Notez que ce répertoire
courant peut toujours être désigné par le caractère~«.»
\begin{shellcom}
  ¢usercom«pwd»
  /home/vincent/LaTeX/cours
\end{shellcom}
\index{home} \index{répertoire!home} \`A chaque utilisateur est
associé un répertoire privé ou \anglais{home directory}. C'est le
répertoire courant après la procédure de login. Pour se rendre dans ce
répertoire, on peut taper la commande \com{cd} sans argument :
\begin{shellcom}
  ¢usercom«cd»
  ¢usercom«pwd»
  /home/vincent
\end{shellcom}
\verb+/home/vincent+ est donc le répertoire privé de l'utilisateur
\texttt{vincent}. Si l'utilisateur est \texttt{lozano}, les commandes
suivantes sont équivalentes à la commande \com{cd} sans argument :
\begin{shellcom}
  ¢usercom«cd ~»
  ¢usercom«cd $HOME»
  ¢usercom«cd ~lozano»
\end{shellcom}
%$
On peut à tout moment changer de répertoire avec la commande \com{cd}
(\anglais{change directory})  qui prend en argument un répertoire, par
exemple :
\framaallongepage{1}
\begin{shellcom}
  ¢usercom«cd /usr/local»
\end{shellcom}
Et, pour illustrer l'utilisation d'une référence relative :
\begin{shellcom}
  ¢usercom«cd /usr»
  ¢usercom«ls -l»
  drwxr-xr-x   8 root     root         4096 Sep 25 00:21 X11R6
  drwxr-xr-x   2 root     root        20480 Nov  5 19:16 bin
  drwxr-xr-x  11 root     root         4096 Nov  5 18:56 ¢rwx«local»
  ¢usercom«cd local» ¢comcomment«utilisation d'une référence relative»
\end{shellcom}
Enfin pour donner un exemple d'utilisation du répertoire~«\texttt{..}»
désignant le répertoire \emph{père} :
\begin{shellcom}
  ¢usercom«pwd»
  /usr/local
  ¢usercom«cd ..»
  ¢usercom«pwd»
  /usr
\end{shellcom}

\subsection{Manipuler les fichiers}
\index{fichier!copie}
Les opérations courantes sur les fichiers sont la copie, le
déplacement ou renommage et l'effacement. Commençons par la copie :
\begin{shellcom}
  ¢usercom«cd ~/LaTeX/cours»
  ¢usercom«ls *.tex»
  truc.tex
  ¢usercom«cp truc.tex muche.tex»
  ¢usercom«ls -l *.tex»
  -rw-r--r--  1 vincent users 1339 Nov  7 21:48 truc.tex
  -rw-r--r--  1 vincent users 1339 Nov  7 21:51 muche.tex
\end{shellcom}
la commande \com{cp} (\emph{copy}) copie donc le fichier donné en
premier argument vers le fichier donné en deuxième argument. Cette
commande accepte également la copie de un ou plusieurs fichiers vers
un répertoire :
\begin{shellcom}
  ¢usercom«cp /usr/local/bin/* .»
\end{shellcom}
cette commande copie tous les fichiers (sauf les sous-répertoires)
contenus dans le répertoire \verb+/usr/local/bin+ dans le répertoire
courant.

\index{fichier!déplacement}
\index{fichier!renommer}
Pour déplacer un fichier, on dispose de la commande \com{mv}
(\emph{move}). De manière quelque peu analogue à la commande \com{cp},
la commande \com{mv} accepte deux formes. La première permet de
\emph{renommer} un fichier :
\begin{shellcom}
  ¢usercom«ls *.tex»
  guide-unix.tex test.tex
  ¢usercom«mv test.tex essai.tex»
  ¢usercom«ls *.tex»
  guide-unix.tex essai.tex
\end{shellcom}
L'autre forme a pour but de \emph{déplacer} un ou plusieurs fichiers
dans un répertoire :
\begin{shellcom}
  ¢usercom«mv essai.tex /tmp»
\end{shellcom}
déplace le fichier \texttt{essai.tex} dans le répertoire \texttt{/tmp}.

\index{fichier!effacer}
La commande \com{rm} (\emph{remove}) efface un fichier. Sous \unix{}
l'effacement d'un fichier est définitif, c'est pourquoi, pour des
raisons de sécurité, l'effacement d'un fichier est généralement
configuré par l'administrateur en mode interactif, c'est-à-dire que le
shell demande à l'utilisateur une confirmation :
\begin{shellcom}
  ¢usercom«rm /tmp/esssai.tex»
  rm: remove `/tmp/essai.tex'?¢comans«yes»
\end{shellcom}
Ici toute autre réponse que « \comans{yes} » ou « \comans{y} » fait échouer
la commande \com{rm}.
\begin{nota}
  Si sur votre système la commande \com{rm} ne vous demande pas de
  confirmation, il faudra faire appel à l'option \texttt{-i} (pour
  interactif). Il est d'ailleurs assez courant de créer un
  \voir[][1\baselineskip]{sec-conf-alias}{alias} pour éviter de le préciser
  systématiquement.
\end{nota}

\subsection{Et les répertoires dans tout ça ?}
\index{répertoire!création}
Et bien on peut en créer là où on a le droit, avec la commande
\com{mkdir} (\anglais{make directory}) par exemple :
\begin{shellcom}
  ¢usercom«mkdir tmp»
  ¢usercom«ls -l»
  «¢normalfont...»
  drwxr-xr-x   2 vincent  users        4096 Nov  7 22:13 tmp
\end{shellcom}
\index{répertoire!effacement}
On peut également détruire un répertoire avec la commande \com{rmdir}
(\anglais{remove directory}) à condition que le répertoire en question
soit vide. On peut cependant effacer un répertoire non vide grâce à la
commande \com{rm} et son option~\texttt{-r}. Cette option
 permet d'effacer \emph{récursivement} le contenu d'un répertoire :
\begin{shellcom}
  ¢usercom«rm -rf tmp»
\end{shellcom}
efface le répertoire \texttt{tmp} ; l'option \texttt{-f} (\emph{force})
est ici cumulée avec l'option de récursion et permet de forcer l'exécution
de la commande \com{rm} en mode non-interactif. L'utilisateur n'est
donc interrogé à aucun moment, c'est donc une forme à utiliser avec
prudence...



\subsection{Gestion des supports amovibles}
\label{sec-survie-amovibles}

Une des grandes interrogations des utilisateurs novices d'\unix{}
concerne l'accès aux supports amovibles (disquettes, cédéroms et
autres clés USB). L'accès à de tels périphériques dépend du système
installé, mais dans tous les cas il consiste à greffer
(\voir{sec-unix-arborescence}{monter}) le système de fichiers du
support amovible à un endroit précis de l'arborescence. Ce montage
peut être réalisé manuellement avec la commande \com{mount}. Dans ce
cas on trouvera dans le fichier \texttt{/etc/fstab} une ligne
ressemblant à :
\begin{verbatim}
  /dev/cdrom  /cdrom    iso9660 ro,user,noauto   0    0
\end{verbatim}
indiquant que l'utilisateur lambda a le droit de monter un système de
fichiers au format Iso9660 contenu dans un cédérom, dans le répertoire
\texttt{/cdrom}. L'utilisateur pourra donc se fendre d'un :
\begin{shellcom}
  ¢usercom«mount /cdrom»
\end{shellcom}
pour avoir accès aux fichiers du dit cédérom à partir du répertoire
\texttt{/cdrom}. Une fois la (ou les) opérations de lecture
effectuée(s) l'utilisateur devra lancer un :
\begin{shellcom}
  ¢usercom«umount /cdrom»
\end{shellcom}
pour détacher le système de fichiers du cédérom de l'arborescence du
système, et pouvoir éjecter le disque du lecteur. 

Certaines versions d'\unix{} utilisent un système de montage
automatique des systèmes de fichiers stockés sur supports amovibles.
Dans ce cas l'accès au répertoire \texttt{/cdrom},
\texttt{/mnt/cdrom}, ou quelque chose de ce genre provoquera le
montage automatique du cédérom. 

\subsection{Changer les droits}
\index{droits!changer|(} Le propriétaire ---~et lui seul~--- a le droit de
changer les permissions associées à un fichier. Seul l'administrateur
(utilisateur \texttt{root}) a la possibilité de changer le
propriétaire d'un fichier (commande \com{chown}). Enfin le groupe
propriétaire peut être changé par le propriétaire  (\com{chgrp}).

\index{propriétaire} \index{fichier!propriétaire} La commande
\com{chmod} permet au propriétaire d'un fichier d'en changer les
droits d'accès soit pour partager des données avec d'autres
utilisateurs, soit au contraire pour rendre des données sensibles
inaccessibles. Cette commande consiste à modifier les privilèges des
trois entités propriétaires d'un fichier (utilisateur, groupe et les
autres). Il existe deux syntaxes de la commande \com{chmod}, la
première est symbolique, l'autre numérique. Nous utiliserons ici plus
volontiers la première en présentant quelques « études de cas » où
l'on désire modifier les droits d'un fichier. Mais avant tout,
posons-nous la question suivante :

\subsubsection{Quels sont les droits par défaut ?}
\index{droits!par défaut}
\index{umask}
Les droits par défaut sont définis par l'intermédiaire d'un
\emph{masque} de création de fichier. En jargon \unix, ce masque est
appelé \emph{umask} pour \emph{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 :
\begin{shellcom}
  ¢usercom«umask -S»
  u=rwx,g=rx,o=rx
\end{shellcom}
Ce qui signifie qu'un fichier est créé avec par défaut :
\begin{itemize}
\item pour le propriétaire : tous les droits ;
\item pour le groupe : 
  \begin{itemize}
  \item droits en lecture  ;
  \item droits en lecture et exécution pour les répertoires ;
   \end{itemize}
 \item idem pour les autres.
\end{itemize}
Nous prendrons comme hypothèse pour nos études de cas que l'umask du
système est celui donné par la commande \verb/umask -S/ ci-dessus.
Créons un répertoire et un fichier dans ce répertoire :
\begin{shellcom}
  ¢usercom«mkdir echange»
  ¢usercom«touch echange/donnees.txt»
\end{shellcom}
La commande \com{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 :
\begin{shellcom}
  ¢usercom«ls -ld echange»
  drwxr-xr-x  2 vincent  users 4096 Nov 18 23:06 echange
  ¢usercom«ls -l echange»
  -rw-r--r--  1 vincent  users    6 Nov 15 21:22 donnees.txt
\end{shellcom}
\index{droits!changer|)}

\subsubsection{Attributs d'un répertoire}
\index{répertoire!attributs}

En considérant le répertoire comme un « catalogue » contenant une
liste de fichiers, on peut voir les trois types de droits comme suit :
\begin{description}
\item[Lecture] : compulser le catalogue, c'est-à-dire lister le contenu du
  répertoire avec la commande \com{ls} par exemple.
\item[Écriture] : modifier le catalogue, donc effacer les fichiers,
  les renommer, les déplacer.
\item[Exécution] : cet attribut permet à un utilisateur de
  \emph{pénétrer} dans ce répertoire et d'accéder aux fichiers qui s'y
  trouvent.
\end{description}
Voyons plus précisément grâce à un exemple :
\begin{shellcom}
  ¢usercom«chmod g-r echange»
  ¢usercom«ls -ld echange»
  drwx¢rwx«-«»-x»r-x  2 vincent  users  4096 Nov 20 18:03 echange
\end{shellcom}
la commande \com{chmod} ci-dessus retire aux membres du groupe
\texttt{users} le droit de lire le répertoire \texttt{echange}. C'est
pourquoi lorsqu'un utilisateur autre que \texttt{vincent} (appelons-le
\texttt{rene}), mais du groupe \texttt{users}, lance la commande :
\begin{shellcom}
  ¢usercom«ls ~vincent/echange»
  ls: /home/vincent/echange/: Permission denied
\end{shellcom}
elle échoue, faute de privilèges suffisants. Ici c'est le droit
d'examiner le \emph{contenu} du répertoire qui n'est pas accordé. Par
contre, la commande :
\begin{shellcom}
  ¢usercom«cat ~vincent/echange/donnees.txt»
\end{shellcom}
est légitime, puisque l'attribut \texttt{x} pour le groupe du
répertoire \texttt{echange} est présent et permet à
l'utilisateur \texttt{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 \texttt{echange} pour le groupe \texttt{users}, comme ceci
:
\begin{shellcom}
  ¢usercom«chmod g-x echange»
  ¢usercom«ls -ld echange»
  drwx¢rwx«-«»-«»-»r-x   2 vincent  users        4096 Nov 20 18:03 echange
\end{shellcom}
la commande suivante, lancée par \texttt{rene} échoue faute de droits
suffisants :
\begin{shellcom}
  ¢usercom«cat ~vincent/echange/donnees.txt»
  cat: /home/vincent/echange/donnees.txt: Permission denied
\end{shellcom}
\begin{attention}
  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.
\end{attention}

\subsubsection{Autoriser un membre du groupe à lire un fichier}

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 :
\begin{enumerate}
\item le répertoire qui contient le fichier est \emph{exécutable} pour
  le groupe en question ;
\item le fichier est lisible pour le groupe.
\end{enumerate}

\subsubsection{Autoriser un membre du groupe à modifier un fichier}
Pour autoriser un membre du groupe propriétaire du fichier
\texttt{donnees.txt} du répertoire \texttt{echange} à modifier un
fichier il suffit d'activer l'attribut \texttt{w} pour le groupe avec
la commande \com{chmod} (en supposant que le répertoire courant est
\texttt{echange}) :
\begin{shellcom}
  ¢usercom«chmod g+w donnees.txt»
  ¢usercom«ls -l donnees.txt»
  -rw-¢rwx«rw-»r-- 1 vincent users  40 Nov 2 18:03 donnees.txt
\end{shellcom}

\subsubsection{Interdire aux autres la lecture d'un fichier}
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 :
\begin{shellcom}
  ¢usercom«chmod o-r donnees.txt»
  ¢usercom«ls -l donnees.txt»
  -rw-rw-¢rwx«-«»-«»-» 1 vincent  users   0 Nov 20 18:03 donnees.txt
\end{shellcom}
interdit aux « autres » l'accès en lecture à \texttt{donnees.txt}


\subsubsection{Autoriser au groupe la suppression d'un fichier}
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 \texttt{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 :
\begin{shellcom}
  ¢usercom«ls -ld echange»
  drwx¢rwx««-»«-»-»r-x   2 vincent  users       4096 Nov 20 18:03 echange
  ¢usercom«chmod g+rwx echange»
  ¢usercom«ls -ld echange»
  drwx¢rwx«rwx»r-x   2 vincent  users       4096 Nov 20 18:03 echange
\end{shellcom}
accorde tous les droits (dont l'attribut \texttt{w}) au groupe
propriétaire sur le répertoire \texttt{echange} ; ce qui permet à
l'utilisateur \texttt{rene} de pouvoir effacer le fichier
\texttt{donnees.txt}.

\subsubsection{Notation symbolique et notation octale}
La commande \com{chmod} telle qu'on l'a vue jusqu'à présent obéit à la
syntaxe suivante :
\ifpdf
\begin{center}
  \includegraphics{octale}
\end{center}
\else
\input{octale}
\fi

Les arguments de la commande \com{chmod} peuvent être constitués de plusieurs blocs
\comarg{p}\comarg{\%}\comarg{a}. Le cas échéant ils doivent être
séparés par des virgules. Les commandes suivantes sont donc correctes
:
\begin{shellcom}
  ¢usercom«chmod o-rwx bidule»
  ¢usercom«chmod g+rx bidule»
  ¢usercom«chmod -w,o+x bidule »
  ¢usercom«chmod a+r bidule»
\end{shellcom}
Dans l'ordre, chacune des commandes précédentes :
\begin{itemize}
\item enlève tous les droits aux autres ;
\item donne les droits en lecture et exécution pour les membres du
  groupe propriétaire ;
\item enlève le droit en écriture pour tout le monde et rajoute
  le droit en exécution pour les autres ;
\item donne à tout le monde le droit en lecture.
\end{itemize}
\index{umask}
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
\texttt{-R} de la commande \com{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 \emph{octale} pour positionner les droits d'un fichier.
Cette notation consiste a coder chaque bloc \texttt{rwx} du bloc de
droits en une donnée numérique de la manière suivante :
\begin{center}
  \fbox{\parbox{1em}{$2^2$\\\texttt{r}}}
  \fbox{\parbox{1em}{$2^1$\\\texttt{w}}}
  \fbox{\parbox{1em}{$2^0$\\\texttt{x}}}
\end{center}
On a alors, par exemple :
\begin{itemize}
\item \texttt{-rwx-{-}-{-}-{-}}  codé par $700$ ;
\item \texttt{-rw{-}r{-}x{r}-{x}} codé par $655$ ;
\item \texttt{-rw{-}r{-}-{r}-{-}}  codé par $644$.
\end{itemize}
Ce codage octal peut être utilisé en lieu et place des symboles
\texttt{gor} et \texttt{rwx} avec la commande \com{chmod}. Il est
également intéressant de noter qu'on peut afficher le \com{umask} en
notation octale :
\begin{shellcom}
  ¢usercom«umask»
  022
\end{shellcom}
Cette valeur est le complément par rapport à $777$. Avec un tel masque
les fichiers sont créés avec les permissions $755$.

\subsection{Liens}
\label{sec-liens}
\index{lien|(}

Une des notions un peu « troublantes » du système de fichiers
d'\unix{} est la notion de lien.  Comme on l'a vu précédemment, en
interne, le système identifie les fichiers par un numéro :
l'\emph{inode}.

\subsubsection{Liens physiques}
\index{lien!physique}

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 \emph{lien physique}. Soit le fichier
\verb|~/doc/unix/guide.tex| :  
\begin{shellcom}
  ¢usercom«cd ~/doc/unix»
  ¢usercom«ls -li guide.tex»
  ¢tfbox«38564» -rw-r--r-- ¢tfbox«1» vincent users 18114 Nov 7 22:44 guide.tex
\end{shellcom}
\index{inode}
on constate que ce fichier (créé par un éditeur de texte) a pour
inode 38564, et ne possède qu'un lien
(\verb|~/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 \texttt{guide.tex}, grâce à la commande \com{ln}
(\anglais{link}) dont la syntaxe est :
\begin{flushleft}
  \quad\verb+ln+ \comarg{cible du lien} \comarg{nom du lien}
\end{flushleft}
Par exemple :
\begin{shellcom}
  ¢usercom«cd ~/tmp»
  ¢usercom«ln ~/doc/unix/guide.tex unix.tex»
  ¢usercom«ls -li unix.tex»
  ¢tfbox«38564» -rw-r--r-- ¢rwx«2» vincent users 18114 Nov 7 22:44 unix.tex
\end{shellcom}
\begin{figure}[htbp]
  \centering
  \includegraphics[width=\ifframabookversion.64\textwidth\else.7\textwidth\fi]{%
    lien_physique}
  \caption{Exemple de liens physiques}
  \label{fig-lien-physique}
\end{figure}
on peut alors constater (figure~\vref{fig-lien-physique}) que
le fichier \texttt{unix.tex} possède maintenant deux liens physiques.
Dans cette situation, il y a donc \emph{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 \emph{deux} noms associés à
cette représentation :
\begin{enumerate}
\item \verb+~/doc/unix/guide.tex+
\item \verb+~/tmp/unix.tex+
\end{enumerate}
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 :
\begin{enumerate}
\item tant que le nombre de liens physiques sur le fichier en question
  est strictement supérieur à 1, la commande \com{rm} aura pour effet
  la suppression du lien et non des données.
\item lorsque le nombre de liens physiques est égal à 1, \com{rm}
  efface effectivement les données, puisqu'il n'y a plus qu'un lien
  unique sur celles-ci.
\end{enumerate}
\begin{attention}
  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 \com{rm}
  mais l'espace qu'occupent les données ne sera libéré que quand le
  dernier processus ayant ouvert le fichier se terminera.
\end{attention}

\subsubsection{Liens symboliques}
\index{lien!symbolique}
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
\emph{symbolique}. Nous allons par exemple créer un lien symbolique
sur notre fichier \texttt{guide-unix.tex} depuis le répertoire
\texttt{/tmp} se trouvant sur une autre partition :
\begin{shellcom}
  ¢usercom«cd /tmp»
  ¢usercom«ln -s ~/doc/unix/guide.tex test.tex»
  ¢usercom«ls -l test.tex»
  lrwxrwxrwx 1 vincent users 32 Nov 21 16:41 test.tex -> /hom
  e/vincent/doc/unix/guide.tex 
\end{shellcom}
Les liens résultants sont indiqués à la
figure~\vref{fig-lien-symbolique}.
\begin{figure}[htbp]
  \centering
  \includegraphics[width=\ifframabookversion.64\textwidth\else.7\textwidth\fi]{%
lien_symbolique}
  \caption{Exemple de lien symbolique.}
  \label{fig-lien-symbolique}
\end{figure}

On remarquera les particularités d'un lien symbolique :
\begin{itemize}
\item c'est un fichier différent de celui sur lequel il pointe ; il
  possède son propre inode :
  \begin{shellcom}
    ¢usercom«ls -i test.tex»
      23902 test.tex
  \end{shellcom}
\item le fichier contient une \emph{référence} sur un autre fichier,
  ce qui explique par exemple que la taille du lien symbolique
  \texttt{test.tex} est de 32, qui correspond aux nombres de
  caractères du chemin du fichier auquel il se réfère ;
\item un lien symbolique est un fichier spécial dont on ne peut
  changer les permissions, ce qui est indiqué par le bloc de droits :
  \begin{flushleft}
    \rwx{l}\verb+rwxrwxrwx+
  \end{flushleft}
\end{itemize}

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 :
\begin{enumerate}
\item la commande \com{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 ;
\item par conséquent, si on supprime le fichier, le lien symbolique
  existe toujours et pointe sur un fichier qui n'existe pas.
\end{enumerate}

\index{répertoire!et lien}
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 \emph{répertoire.} Par exemple :
\begin{shellcom}
  ¢usercom«cd»
  ¢usercom«ln -s /usr/share/texmf/tex/latex macros»
  ¢usercom«ls -l macros»
  lrwxrwxrwx  1 vincent users 26 Nov 21 17:02 macros -> /usr/sh
  are/texmf/tex/latex
\end{shellcom}
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 \emph{raccourci} de
Windows\registered. 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.  \index{raccourci} \index{lien|)}

\begin{note}
  Il peut être intéressant de noter que les commandes internes \com{cd}
  et \com{pwd} comprennent deux options :
  \begin{itemize}
  \item \texttt{-L} pour demander explicitement à suivre les liens
    symboliques ;
  \item \texttt{-P} pour demander à suivre la structure physique de l'arborescence.
  \end{itemize}
\end{note}

\subsection{Access control list (ACL)}
\label{sec-unix-acl}

\subsubsection{Limites de la gestion des privilèges}

Nous avons vu à partir de la section~\vref{sec-unix-privileges}
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 :
\begin{enumerate}
\item les privilèges de l'utilisateur propriétaire.
\item ceux du groupe propriétaire.
\item ceux des autres.
\end{enumerate}
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~$\lambda$ et uniquement à lui,
il n'y a pas d'autre solution que de créer un groupe~$\gamma$ auquel
$\lambda$ appartient, puis d'accorder les droits de lecture et
d'écriture au groupe~$\gamma$. 

Imaginons que deux utilisateurs ---~dont les noms de connexion sont
\texttt{andy} et \texttt{debrah}~--- veuillent collaborer sur le contenu
d'un fichier \texttt{poodle.dat}. Tout
d'abord, l'administrateur doit créer un groupe (nommons-le
\texttt{zircon}) puis faire en sorte que \texttt{andy} et
\texttt{debrah} deviennent membres de ce groupe. Ensuite l'utilisateur
initialement propriétaire du fichier \texttt{poodle.dat} (par exemple
\texttt{andy}) doit positionner les privilèges sur celui-ci :
\begin{shellcom}
  ¢usercom«ls -l poodle.dat»
  -rw-r--r-- 1 andy users  3100 2009-05-11 22:51 poodle.dat
  ¢usercom«chgrp zircon poodle.dat»
  ¢usercom«chmod g+rw poodle.dat»
  ¢usercom«ls -l poodle.dat»
  -rw-¢rwx«rw-»r-- 1 andy ¢rwx«zircon» 3100 2009-05-11 22:51 poodle.dat
\end{shellcom}
À partir de maintenant, l'utilisateur \texttt{debrah} peut lire et
modifier le contenu du fichier \texttt{poodle.dat}.
\begin{nota}
  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.
\end{nota}

\subsubsection{Introduction aux ACL}

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 :
\begin{itemize}
\item \com{getfacl} examen des autorisations d'un fichier ;
\item \com{setfacl} positionnement de ces autorisations.
\end{itemize}
\begin{nota}
  Le système de fichier devra supporter les ACLs. Sous le système
  \gnu/\linux{} il faudra le spécifier explicitement dans les options de
  montage contenues dans le fichier \texttt{/etc/fstab}. Le système de
  votre serviteur contient par exemple :
\begin{verbatim}
   /dev/sdb5    /home   ext3    acl,defaults        0       2
\end{verbatim}
  \continuenota%
  indiquant que la partition \texttt{/dev/sdb5} est montée dans le
  répertoire \texttt{/home} avec support pour les ACLs.
\end{nota}

\paragraph{Accorder des droits à un utilisateur}

Reprenons l'exemple de nos deux compères \texttt{andy} et \texttt{debrah} 
 souhaitant tous deux collaborer sur le fichier 
\texttt{poodle.dat} :
\begin{shellcom}
  ¢usercom«ls -l poodle.dat»
  -rw-r--r-- 1 andy users  3100 2009-05-11 22:51 poodle.dat
\end{shellcom}
Pour autoriser \texttt{debrah} à lire et modifier le fichier en question, \texttt{andy} devra taper :
\begin{shellcom}
  ¢usercom«setfacl -m u:debrah:rw poodle.dat»
\end{shellcom}
La syntaxe
\begin{flushleft}
  \com{setfacl} -m u:\marg{user}:\marg{perm} 
\marg{fichier}
\end{flushleft}
permet donc de \emph{modifier} (c'est le sens de l'option \texttt{m})
les autorisations de l'utilisateur \comarg{user} (argument
\texttt{u:}). Les autorisations \comarg{perm} peuvent être définies en
utilisant la notation symbolique présentée au
paragraphe~\vref{sec-unix-privileges}.
\begin{note}
  Comme la commande \com{chmod}, \com{setfacl} autorise
  l'option~\texttt{-R} pour accorder les droits spécifiés à tous les
  fichiers et sous-répertoires, récursivement.
\end{note}

\paragraph{Examiner les autorisations associées à un fichier}

L'option \texttt{-l} de la commande \com{ls} propose un affichage
légèrement modifié lorsque des autorisations ACLs sont associées à un
fichier :
\begin{shellcom}
  ¢usercom«ls -l poodle.dat»
  -rw-rw-r--+ 1 andy users  3100 2009-05-11 22:51 poodle.dat
\end{shellcom}
Notez la présence du signe \texttt{+}. La commande \com{getfacl}
permet de lister les permissions associées :
\begin{shellcom}
  ¢usercom«getfacl poodle.dat»
  # file: poodle.dat
  # owner: lozano ¢comcomment«propriétaire»
  # group: lozano ¢comcomment«groupe propriétaire»
  user::rw-       ¢comcomment«droits du propriétaire»
  user:debrah:rw-  ¢comcomment«droits de l'utilisateur debrah»
  group::r--      ¢comcomment«droits du groupe propriétaire»
  mask::rw-       ¢comcomment«cf. plus bas»
  other::r--      ¢comcomment«droits des autres»
\end{shellcom}

\paragraph{Accorder des droits par défaut dans un répertoire}

Grâce à l'option \texttt{-d} de la commande \com{setfacl} on peut
accorder des droits par défaut à un répertoire. En reprenant l'exemple
précédent, la commande :
\begin{shellcom}
  ¢usercom«setfacl -d -m u:muffin:rw .»
\end{shellcom}
permet d'autoriser la lecture et l'écriture à l'utilisateur
\texttt{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 \texttt{muffin}. 
\begin{attention}
  Attention, la commande de l'exemple ci-dessus n'accorde pas à
  l'utilisateur \texttt{muffin} de créer des fichiers dans le
  répertoire courant.  
\end{attention}
Enfin, les droits par défaut peuvent être retirés avec l'option
\texttt{-k}. Ici la commande :
\begin{shellcom}
  ¢usercom«setfacl -k .»
\end{shellcom}
supprime les droits par défaut sur le répertoire courant.


\paragraph{Révoquer des droits}

Pour supprimer les droits ajoutés avec la  \com{setfacl} et
son option~\texttt{-m} on peut utiliser :
\begin{itemize}
\item l'option \texttt{-b} pour supprimer tous les droits de type ACL
\item l'option \texttt{-x} pour supprimer un entrée, par exemple :
\begin{shellcom}
  ¢usercom«setfacl -x u:debrah poodle.dat»
\end{shellcom}
révoque les droits accordés sur le
fichier \texttt{poodle.dat} à l'utilisateur \texttt{debrah}.
\end{itemize}

\paragraph{Masque ACL}
Lorsqu'au moins un privilège de type ACL a été accordé à un fichier,
un \emph{masque} est créé contenant l'union de toutes les
autorisations. Ce masque est construit automatiquement, ainsi :
\begin{shellcom}
  ¢usercom«setfacl -m u:dinah:r righthereonthe.floora»
  ¢usercom«setfacl -m u:moe:r   righthereonthe.floora»
  ¢usercom«setfacl -m u:hum:rw  righthereonthe.floora»
\end{shellcom}
Le masque créé et affiché par la commande \com{getfacl} sera :
\begin{shellcom}
  ¢usercom«getfacl righthereonthe.floora»
  [...]
  user::dinah:r--
  user::moe:r--
  user::hym:rw-
  [...]
  mask::rw- ¢comcomment«union des trois permissions précédentes»
  [...]
\end{shellcom}
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 :
\begin{shellcom}
  ¢usercom«setfacl -m m::r righthereonthe.floora»
\end{shellcom}

%===================================================================
%
%    PROCESSUS
%
%===================================================================
\section{Processus}
\label{sec-processus}
\index{processus|(}

\index{ordonnanceur}
\index{scheduler@\anglais{scheduler}}
Le système \unix{} est multi-tâche et multi-utilisateur. Le noyau gère
l'ensemble des processus grâce à un programme appelé
\emph{l'ordonnanceur} (\anglais{scheduler}). Ce dernier a pour but
d'accorder aux processus du temps-cpu, et ceci chacun à tour de rôle,
en fonction de priorités le cas échéant. Ainsi, un processus peut se
trouver dans quatre états :
\begin{description}
\item[actif :] le processus utilise le cpu
\item[prêt :] le processus attend que l'ordonnanceur lui fasse signe 
\end{description}
mais également :
\begin{description}
\item[endormi :] le processus attend un évènement particulier (il ne
  consomme pas de cpu dans cet état) ;
\item[suspendu :] le processus a été interrompu par un
  \voir{sec-signaux}{signal}.
\end{description}
\index{processus!état}
\index{priorité!d'un processus}
\index{endormi (processus)}
\index{actif (processus)}
\index{suspendu (processus)}
\index{identificateur!de processus}
\index{pid}

Chaque processus possède un numéro qui l'identifie auprès du système.
Ce numéro est appelé son \emph{pid} ou \emph{process identifer}. On
verra plus bas que chaque processus à l'exception du tout premier
créé, possède un processus père qui lui donne naissance. Ainsi
l'ensemble des processus d'un système \unix{} constitue un
\emph{arbre} de processus.

\index{terminal} On notera ici qu'à la notion de processus, on associe
généralement la notion de \emph{terminal}. Un terminal est un canal de
communication entre un processus et l'utilisateur. Il peut
correspondre à un terminal physique comme un écran ou un clavier, mais
aussi à ce qu'on appelle un émulateur de terminal comme une fenêtre
XTerm.  Dans les deux cas un fichier spécial dans le répertoire
\texttt{/dev} (par exemple \texttt{/dev/tty1} est la première console
en mode texte, sous linux) est associé au terminal, et les
communications se font par le biais d'appels système sur ce fichier.
La variable \envvar{TERM} informe les applications sur le comportement
du terminal (entre autres choses, la manière dont les caractères de
contrôle seront interprétés).


\subsection{Examiner les processus}
\label{sec-exam-les-proc}
\index{processus!lister}
La commande \com{ps} permet d'examiner la liste des processus «
tournant » sur le système. Cette commande comprend un nombre très
important d'options qui sont généralement différentes selon les
systèmes, il n'est donc pas question ici de les passer toutes en revue
(pour ça il suffit de taper \texttt{man ps} !). Voyons tout de même
quelques exemples instructifs.
\begin{gnuposix}
  Notez qu'un certain nombre d'options de la commande \com{ps} a fait
  l'objet de standardisation notamment au travers de la
  \anglais{Single Unix Specification} (SUS) portée par l'Open Group,
  consortium ayant pour but de standardiser ce que devrait être un
  système \unix{}. Par exemple, la commande \com{ps} de la
  distribution Debian actuelle est censée respecter les
  recommandations de la SUS version~2. Encore une fois, vous trouverez
  dans ce qui suit des options ne respectant pas nécessairement tous
  ces standards, veuillez nous en excuser par avance.
\end{gnuposix}
\subsubsection{Ceux du terminal}
\label{sec-ceux-du-terminal}
\index{terminal!et processus}

J'ai lancé \soft{Emacs} (éditeur de texte grâce auquel je tape ce
document) dans une fenêtre xterm ; voici ce que me donne la commande
\com{ps} dans cette fenêtre :
\begin{shellcom}
  ¢usercom«ps»
   PID TTY          TIME CMD
  1322 ttyp2    00:00:43 bash
  1337 ttyp2    00:02:04 emacs
  1338 ttyp2    00:00:00 ps
\end{shellcom}
On obtient donc une liste dont la première colonne contient le
\emph{pid} de chaque processus, chacun de ces processus est associé
au pseudoterminal du xterm désigné par \texttt{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 \com{ps} est lancée pour
obtenir la liste des processus, son pid apparaît également dans la
liste (ici pid 1338). 


\subsubsection{Ceux des autres terminaux}
\label{sec-ceux-des-autres}
\index{terminal!et processus}

L'option \texttt{x} de la commande \com{ps} permet de lister les
processus de l'utilisateur qui ne sont par rattachés au terminal
courant\footnote{Liste non exhaustive par souci de clarté.} :
\begin{shellcom}
  ¢usercom«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
\end{shellcom}
La nouvelle colonne \texttt{STAT} (\anglais{status}) donne l'état de
chaque processus, ici \texttt{S} indique que le processus est endormi
(\anglais{sleeping}), et \texttt{R} qu'il est prêt
(\anglais{runnable}).


\subsubsection{Ceux des autres utilisateurs}
\label{sec-ceux-des-autres-user}
\index{utilisateur!processus des}
\index{processus!des utilisateurs}

La syntaxe suivante permet d'obtenir la liste des processus lancés par
un utilisateur du système :
\begin{shellcom}
  ¢usercom«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
\end{shellcom}
L'utilisateur \texttt{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.


\subsubsection{Tous !}
\label{sec-tous-ps}

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 \com{ps} de \linux{} supporte plusieurs styles
de syntaxes ; nous en donnons ci-dessous deux exemples :
\framaallongepage{1}
\begin{shellcom}
  ¢usercom«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
\end{shellcom}
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
\texttt{START}), ainsi que le pourcentage de cpu et de mémoire
utilisés (\texttt{\%CPU} et \texttt{\%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 \texttt{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 :
\begin{shellcom}
  ¢usercom«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
\end{shellcom}
ici l'affichage est quelque peu différent. \texttt{STIME} est
l'équivalent du \texttt{START}, et on a accès au \texttt{ppid} qui
identifie le processus \texttt{père} d'un processus particulier. On
remarquera dans cette liste que tous les processus sont des fils
d'\texttt{init} ---~c'est-à-dire lancés par celui-ci. Ceci à l'exception
d'\texttt{init} lui-même qui est le premier processus créé.


\subsubsection{Personnaliser l'affichage}
\label{sec-pers-laff}

On peut se limiter à certaines informations en utilisant
l'option~\texttt{o} de la commande \com{ps} ; cette option permet de
spécifier les champs que l'on désire voir s'afficher, par exemple :
\begin{shellcom}
  ¢usercom«ps -xo pid,cmd»
  PID CMD
  346 [.xsession]
  360 fvwm2 -s
  363 xterm -ls -geometry 80x30+0+0
  367 -bash
  428 man fvwm2
\end{shellcom}
n'affiche que le pid et la commande d'un processus. On a combiné ici
l'option~\texttt{o} avec l'option~\texttt{x} vue précédemment.

\subsubsection{Lien de parenté}
\index{processus!parents}

\label{sec-lien-de-parente}
L'option \texttt{-{-}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.
\begin{shellcom}
  ¢usercom«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
\end{shellcom}


\subsection{Modifier le déroulement d'un processus}
\label{sec-modif-le-dero}

Il existe au moins trois manières de modifier le déroulement normal
d'un processus :
\begin{enumerate}\label{sec-signaux}
\item changer la priorité d'un processus avec la commande \com{nice} ;
\item utiliser la commande \com{kill}. Cette commande permet à
  partir du pid d'un processus, d'envoyer ce qu'on appelle en jargon
  \unix{}, un \emph{signal} à ce processus. En tant qu'utilisateur du
  système, on envoie généralement des signaux pour interrompre,
  arrêter ou reprendre l'exécution d'un programme ;
\item utiliser le contrôle de tâche (\anglais{job control}) depuis le
  shell. Ce mécanisme permet de modifier le déroulement des programmes
  s'exécutant dans un terminal donné.
\end{enumerate}


\subsubsection{Priorité d'un processus}
\index{processus!priorité}
\index{priorité!d'un processus}

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 \com{nice} :
\begin{shellcom}[noendprompt]
  ¢usercom«nice -n ¢comarg«priorité»./groscalcul»
\end{shellcom}
où $-20 \leq \mbox{\comarg{priorité}} \leq 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 \com{renice} permettant de baisser
la priorité d'un processus une fois qu'il est lancé. Par exemple, avec
la commande :
\begin{shellcom}
  ¢usercom«renice -10 -p 4358»
  4358: old priority 0, new priority 10
\end{shellcom}
on change la priorité du processus de pid~4358 en lui affectant la
valeur~10.

\subsubsection{La notion de signal}
\index{signal}
\index{processus!et signaux}

Lorsqu'on veut interrompre ou suspendre un processus, l'intervention
revient toujours à envoyer ce qu'on appelle un \emph{signal} au
processus en question. Lorsqu'un processus reçoit un signal il
interrompt le cours normal de son exécution et peut :
\begin{itemize}
\item soit s'arrêter, c'est le comportement par défaut ;
\item soit exécuter une routine particulière que le concepteur de la
  commande aura eu soin de définir et reprendre son cours normal.
\end{itemize}
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 \com{kill} et l'option \texttt{-l}.
\begin{shellcom}
  ¢usercom«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
\end{shellcom}
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 \texttt{KILL} (\no9) et du signal \texttt{STOP}
(\no19) qui ne peuvent être détournés et donc ont toujours pour
effet d'arrêter (respectivement d'interrompre) le processus.


\subsubsection{La commande \com{kill}}
\label{sec-la-comm-kill}

Nous passerons ici en revue quelques utilisations de la commande
\com{kill}. Dans un cadre très pratique, il y a trois situations
vitales où il est nécessaire de connaître cette commande :
\begin{enumerate}
\item 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 ;
\item un programme utilise trop de ressources pour le confort des
  autres utilisateurs, il est nécessaire de l'interrompre
  momentanément ;
\item 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.
\end{enumerate}

Passons en revue ces trois situations en supposant que sur notre
terminal la commande \com{ps} nous renvoie :
\begin{shellcom}
  ¢usercom«ps -o pid,pcpu,pmem,state,cmd»
  PID %CPU %MEM S CMD
  2177  0.0  2.1 S -bash
  ¢tfbox«2243» 99.9 99.9 R winword-2005
  2244  0.0  1.7 R ps -o pid,pcpu,pmem,state,cmd
\end{shellcom}

\paragraph{Anti-emballement}
\label{sec-anti-emballement}
\index{signal!kill@\texttt{KILL}}

On décide que le programme \texttt{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 :
\begin{shellcom}
  ¢usercom«kill 2243»
\end{shellcom}
ce qui a pour effet d'envoyer le signal \texttt{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 \texttt{KILL} :
\begin{shellcom}
  ¢usercom«kill -KILL 2243»
\end{shellcom}
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é.

\paragraph{Assurer le confort des autres}
\label{sec-assurer-le-confort}
\index{signal!stop@\texttt{STOP}}
\index{processus!interrompre}

On considère ici que le fameux programme \texttt{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'\emph{interrompre} le programme pour
le reprendre plus tard :
\begin{shellcom}
  ¢usercom«kill -STOP 2243»
\end{shellcom}
On peut constater que le programme interrompu est effectivement dans
cet état en examinant le champ \texttt{STATE} :
\begin{shellcom}
  ¢usercom«ps -o pid,pcpu,pmem,state,cmd»
  PID %CPU %MEM S CMD
  2177  0.0  2.1 S -bash
  ¢rwx«2243»  0.0 25.3 T winword-2005
  2244  0.0  1.7 R ps -o pid,pcpu,pmem,state,cmd
\end{shellcom}
Ce champ est positionné à \texttt{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 :
\begin{shellcom}
  ¢usercom«kill -CONT 2243»
\end{shellcom}
qui indique au processus de pid 2243 de reprendre son exécution.
\index{signal!cont@\texttt{CONT}}
\index{processus!rependre}

\subsubsection{Contrôle de tâches}
\label{sec-le-controle-de-tache}
\index{processus!en arrière-plan}
\index{processus!en avant-plan}
\index{arrière plan}
\index{avant-plan}
\index{tâche!de fond}
\index{processus!en tâche de fond}

Le contrôle de tâches ou \anglais{job control} permet de manipuler les
processus tournant sur un terminal donné. Sur chaque terminal, on
distingue deux types de processus :
\begin{enumerate}
\item le processus en \emph{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 « a la main » sur ce type
  de processus ;
\item les processus en \emph{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.
  \begin{note}
    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~\texttt{TTOU}
    et~\texttt{TTIN} (respectivement écriture ou lecture d'un
    processus en arrière-plan), le comportement pourra être différent.
  \end{note}
\end{enumerate}

Les shells supportant le contrôle de tâches\footnote{Ce qui est le cas
  de la plupart des shells modernes.} offrent un certain nombre de
commandes et de combinaisons de touches qui permettent entre autres :
\begin{itemize}
\item d'interrompre ou d'arrêter un programme ;
\item de passer un programme en arrière ou en avant-plan ;
\item de lister les processus en arrière-plan.
\end{itemize}

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{} :
\begin{shellcom}[noendprompt]
  ¢usercom«emacs»
\end{shellcom}
Une fois \emacs{} lancé, l'utilisateur n'a plus la main sur le
terminal\footnote{Sauf si \emacs{} est lancé en mode texte dans le
  terminal...}, et tout caractère saisi reste en attente, jusqu'à la
fin de l'exécution d'\emacs{} :
\begin{shellcom}
  ¢usercom«emacs»
  ¢usercomwop«qdqsqmlskdjf»
  ¢comcomment«fin du progamme emacs»
  ¢usercom«qdqsqmlskdjf»
  bash: qdqsqmlskdjf: command not found
\end{shellcom}


\subsubsection{Arrêter le programme}
\index{control-c}

Pour arrêter un programme en avant-plan, on peut utiliser la célèbre
combinaison de touche \touche{Ctrl}\touche{c} (\texttt{Ctrl-c}) :
\begin{shellcom}
  ¢usercom«emacs»
       ¢comcomment«Control + c»
\end{shellcom}
\texttt{Ctrl-C} envoie le signal \texttt{INT} au processus en
avant-plan dans le terminal.


\subsubsection{Passage en arrière-plan}
\index{control-z}

Pour passer \emacs{} (le programme de notre exemple) en arrière-plan,
il faut procéder en deux temps : appuyer sur la touche
\touche{Control} puis la touche \touche{z} en même temps (on note
souvent \texttt{Ctrl-z})\footnote{Cette combinaison est généralement
  celle que l'on trouve sur un système \unix{}, mais notez que cela
  peut être différent sur certains systèmes.}, ce qui a pour effet
d'envoyer le signal \texttt{STOP} au programme s'exécutant en
avant-plan sur le terminal.
\begin{shellcom}
  ¢usercom«emacs»
  ¢comcomment«Control + z»
  [1]+  Stopped            emacs
\end{shellcom}
Il faut ensuite passer le programme en tâche de fond grâce à la
commande interne~\texttt{bg} (\anglais{background}) :
\begin{shellcom}
  ¢usercom«bg»
  [1]+ emacs &
\end{shellcom}
Le numéro entre crochet (\texttt{[1]}) est le numéro de la tâche dans
le terminal courant. On parle aussi de \anglais{job}.  On peut
également lancer directement une commande ou programme en tâche de
fond, en postfixant la commande par le caractère~\texttt{\&} :
\begin{shellcom}
  ¢usercom«emacs&»
  [1] 1332
\end{shellcom}
Ici le système attribue à \emacs{} le job \texttt{[1]}, et le shell
affiche sur le terminal le pid correspondant (1332). 


\subsubsection{Lister  les tâches}
\index{tâche!en arrière-plan}

La commande \texttt{jobs} permet d'obtenir une liste des tâches en
arrière-plan, ou interrompues, sur le terminal. Par exemple :
\begin{shellcom}
  ¢usercom«xclock & xlogo & xbiff &»
  [1] 1346
  [2] 1347
  [3] 1348
\end{shellcom}
lance trois programmes donnant lieu à la création d'une fenêtre
graphique. On peut lister ces tâches :
\begin{shellcom}
  ¢usercom«jobs»
  [1]   Running                 xclock &
  [2]-  Running                 xlogo &
  [3]+  Running                 xbiff &
\end{shellcom}


\subsubsection{Passage en avant-plan}
\index{processus!en avant-plan}

Il est possible de faire référence à une tâche par son numéro grâce à
la notation \texttt{\%}\comarg{numéro\_de\_tâche}. Ceci est valable pour
les commandes \com{bg} et \com{kill} vues précédemment, mais aussi pour
la commande permettant de passer une tâche en avant-plan : la commande
\com{fg} (\anglais{foreground}).  Ainsi par exemple pour passer
\texttt{xlogo} en avant-plan :
\begin{shellcom}[noendprompt]
  ¢usercom«fg %2»
  xlogo
  ¢comcomment«maintenant on n'a plus la main.»
\end{shellcom}
\index{processus|)}

%===================================================================
%
%    SERVICES
%
%===================================================================

\section{Quelques services}
\label{sec-services}

Un système d'exploitation peut être vu comme une couche logicielle
faisant l'interface entre la machine et l'utilisateur. Cette interface
peut elle-même être appréhendée comme un ensemble de services fournis à
l'utilisateur. Outre les services vus jusqu'ici permettant de lancer
des programmes et de stocker des données\footnote{Seront étudiés plus
  loin dans ce manuel les services liés à la communication entres
  utilisateurs, et le téléchargement de fichiers.}, il existe ---~entre
autres~--- des services liés à l'impression et la planification.

Les services d'\unix{} répondent généralement au principe
client/serveur, dans lequel le client est l'application vue par
l'utilisateur, et le serveur un \emph{daemon} (disk and execution
monitor), c'est-à-dire un programme attendant en tâche de fond, pour
répondre aux éventuelles requêtes.
\index{daemon}
\index{service!daemon}

\subsection{Impression}
\label{sec-print}
\index{impression}
\index{service!impression}

Sur les réseaux locaux, l'impression sous \unix{} se fait généralement
sur des imprimantes PostScript connectées à un réseau. Le PostScript
est un langage d'impression conçu par la société Adobe, c'est un
langage de description de page. Ce langage est \emph{interprété}, et
les imprimantes dites PostScript disposent d'un interpréteur implanté
sur une carte électronique. Le principe pour imprimer est donc
d'envoyer un fichier au format PostScript sur une \index{PostScript}
imprimante. En fonction du format du fichier initial, il faudra
procéder à une conversion avec les logiciels suivants :
\begin{itemize}
\item \soft{a2ps} convertit un fichier texte en fichier PostScript ;
\item \soft{convert} permet de convertir à peu près n'importe quel
  type d'image en PostScript  ;
\item \soft{dvips} permet de convertir la sortie de \TeX{} (format
  \texttt{dvi}) en PostScript.
\end{itemize}
%% Ces trois utilitaires peuvent se trouver respectivement à :
%% \begin{itemize}
%% \item \url{http://www-inf.enst.fr/~demaille/a2ps} 
%% \item \url{http://www.imagemagick.org}
%% \item \url{http://www.mathematik.uni-bielefeld.de/tex/texi2html/dvips.html}
%% \end{itemize}
Si l'on ne dispose pas d'imprimante PostScript, il faut générer le
PostScript comme indiqué précédemment et utiliser un \emph{interpréteur
  logiciel} pour transformer ce PostScript en fichier compatible avec
l'imprimante en question (voir figure~\vref{fig-printing}).
L'interpréteur PostScript couramment utilisé sous \unix{} est
Ghostscript (\url{http://www.cs.wisc.edu/~ghost}).
\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=.7\textwidth]{printing}
    \caption{Impression sous Unix.}
    \label{fig-printing}
  \end{center}
\end{figure}
Les commandes de base disponibles pour l'utilisateur sont :
\begin{itemize}
\item \com{lpr} : pour soumettre un fichier à imprimer ;
\item \com{lpq} : pour lister la liste des « jobs » d'impression en
  attente ;
\item \com{lprm} : pour enlever un job de la liste en attente.
\end{itemize}
Selon le système que vous utiliserez seront accessibles plusieurs
files d'impression en fonction des imprimantes disponibles. Seront
également accessibles des options dépendantes des caractéristiques de
l'imprimante (alimentation manuelle, bac~A3, recto/verso, etc.).
Renseignez-vous auprès du môssieur qui vous sert d'administrateur
système.
\begin{gnuposix}
  Il existe deux familles de commandes héritées de deux versions
  d'\unix{}. Historiquement, la branche BSD proposait les commandes
  \com{lp}, \com{lpq} et \com{lprm}, et les commandes correspondantes
  de la branche SysV étaient \com{lp}, \com{lpstat} et \com{cancel}.
  Aujourd'hui les programmes gérant l'impression sur un système
  \unix{} peuvent utiliser l'une ou l'autre de ces familles, voire les
  deux.
\end{gnuposix}

\subsection{Le service \com{at}}
\label{sec-at}
\index{services!at}


La commande \com{at} permet de lancer une commande à (\emph{at}) une
heure particulière. Sa syntaxe est la suivante :
\begin{comsyntax}
  at \comarg{date}
\end{comsyntax}
On pourra par exemple lancer :
\begin{shellcom}
  ¢usercom«at 23:00»
  at> groscalculdelamort
  at> ¢comcomment«Ctrl-D»
\end{shellcom}
pour lancer à 23 heures le programme \texttt{groscalculdelamort} qui
utilise beaucoup de ressources. La sortie du programme sera envoyée par
mail à l'utilisateur après son exécution. D'autres syntaxes existent
pour spécifier la date de lancement :
\begin{shellcom}
  ¢usercom«at now + 2hours»
\end{shellcom}
pour lancer un programme dans deux heures. Et :
\begin{shellcom}
  ¢usercom«at 16:20 tomorrow»
\end{shellcom}
pour demain à 16:20,
\begin{shellcom}
  ¢usercom«at  13:14 10/23/02»
\end{shellcom}
pour lancer un programme le 23 octobre 2002 à 13 heures 14. On peut
également lister les « jobs » prévus par la commande \com{at} grâce à
la commande \com{atq} :
\begin{shellcom}
  ¢usercom«atq»
  1       2001-03-14 18:27 a
  2       2001-03-15 16:20 a
  3       2002-10-23 13:14 a
\end{shellcom}
La commande \com{atrm} quant à elle, permet de supprimer une tâche
prévue, en donnant son identificateur (le numéro indiqué dans la
première colonne des informations renvoyées par \com{atq}) :
\begin{shellcom}
  ¢usercom«atrm 1»
\end{shellcom}
On peut également préparer les commandes dans un fichier texte et
utiliser ce fichier ---~notons-le \texttt{commandes.at}~--- comme argument
de la commande \com{at} :
\begin{shellcom}
  ¢usercom«at -f commandes.at 15:00 tomorrow»
\end{shellcom}

\subsection{Le service \com{cron}}
\label{sec-cron}
\index{service!cron}

\com{cron} est un service équivalent à ce que le système
d'exploitation édité par la société Microsoft appelle les « tâches
planifiées ».  L'interface utilisateur est la commande
\com{crontab}. Pour savoir quelles sont vos tâches planifiées (dans le
jargon \unix{}, on dit inspecter « sa crontab »), on lancera la
commande :
\begin{shellcom}
  ¢usercom«crontab -l»
  no crontab for djobi
\end{shellcom}
Pour effacer toutes vos tâches planifiées, la commande suivante suffira :
\begin{shellcom}
  ¢usercom«crontab -r»
\end{shellcom}
Pour définir une ou plusieurs tâches planifiées, la commande :
\begin{shellcom}[noendprompt]
  ¢usercom«crontab -e»
\end{shellcom}
lance un éditeur (qui peut être par défaut
\voir[][2pt]{sec-conf-vi}{\com{vi}}) qui vous demande de saisir des
informations dans un format particulier.  Chaque ligne ce celui-ci
devra contenir les informations suivantes :
\begin{center}
  \comarg{minutes} \comarg{heures} \comarg{jour du mois} \comarg{mois}
  \comarg{jour de la semaine} \comarg{commande}
\end{center}
où :
\begin{fwlitemize}{3.5cm}
\item[\comarg{minutes}]: prend des valeurs de 0 à 59 ;
\item[\comarg{heures}]: de 0 à 23 ;
\item[\comarg{jour du mois}]: de 1 à 31 ;
\item[\comarg{mois}]: de 1 à 12 ;
\item[\comarg{jour de la semaine}]: de 0 à 7 où 0 et 7 représentent le
  dimanche.
\end{fwlitemize}
Par exemple la ligne :
\begin{verbatim}
   10 0 * * 0 rm -rf ~/.wastebasket/*
\end{verbatim}
\framaallongepage{2}efface tous les
dimanches à minuit passé de dix minutes, le contenu du répertoire «
poubelle~» \texttt{\~{}/.wastebasket}.  La ligne :
\begin{verbatim}
   0 12 30 12 * echo "bon anniversaire" | mail pote@truc.net 
\end{verbatim}
envoie un \voir{sec-com-mail}{mail} à votre pote tous les 30 décembre
à midi.  
\framanouvellepage
\noindent La ligne :
\begin{verbatim}
   0 8-18 * * * echo "ça gaze ?" | mail pote@truc.net
\end{verbatim}
envoie un mail toutes les heures pile de (8~heures à 18~heures) pour
vous rappeler à son bon souvenir. La ligne :
\begin{verbatim}
   0 8-18/4 * * 1,3,5 rm -f ~/tmp/*
\end{verbatim}
vidange le répertoire \texttt{tmp} de l'utilisateur le lundi, mercredi
et le jeudi, et ceci de 8~heures à 18~heures, toutes les 4~heures.
Notez enfin que le service \com{cron} vous informe par mail du
résultat de l'exécution de votre tâche. Voir la page de manuel de
\com{crontab} pour de plus amples informations, ainsi que l'exemple du
chapitre~\ref{chap-configurer} paragraphe~\vref{sec-X-cas} illustrant
une utilisation du service \soft{cron} pour mettre des images tirées
au hasard en fond d'écran.

\subsection{L'utilitaire \com{nohup}}
\label{sec-nohup}

\com{nohup} permet de lancer une commande qui ne sera pas arrêtée
lorsque l'utilisateur se déconnectera du système\footnote{Il ne
  s'agit donc par réellement d'un service de planification, mais d'une
  commande utile dans le cadre de la gestion des tâches.}. Lors de la
déconnexion, tous les programmes reçoivent en effet le signal
\texttt{HUP}, qui a par défaut l'effet de les arrêter\footnote{Notons
  cependant que certains logiciels sont programmés pour détourner ce
  signal.}. Pour lancer la commande \comarg{cmd} « en \com{nohup} », on
tapera :
\begin{comsyntax}
  nohup  \comarg{cmd}
\end{comsyntax}
Par exemple pour lancer un téléchargement qui va durer plusieurs
heures, on peut utiliser \voir{sec-wget}{\soft{wget}} avec \com{nohup}
:
\begin{shellcom}
  ¢usercom«nohup wget ftp://bidule.chouette.org/pub/truc-1.2.tar.gz»
  nohup: appending output to `nohup.out'
  ¢comcomment«Ctrl-z»
  [1]+  Stopped                 wget
  ¢usercom«bg»
  [1]+ wget &
\end{shellcom}
Le système vous informe alors que la sortie du programme ---~en
l'occurrence \soft{wget}~--- est \voir{sec-redirection}{redirigée} dans
le fichier \texttt{nohup.out}. Fichier qu'on pourra consulter lors de
la prochaine connexion au système.
\begin{note}
  Que faire alors si le programme lancé avec \texttt{nohup} est un
  programme interactif qui attend des données au clavier ? Une
  solution simple est de visualiser le contenu du fichier
  \texttt{nohup.out} dans un autre terminal avec la commande
  \voir{sec-tail-head}{\texttt{tail -f nohup.out}} et répondre aux
  questions dans le terminal où est lancé la commande en
  \texttt{nohup}. Par exemple si on ne dispose pas de \soft{wget} mais
  uniquement de l'utilitaire \com{ftp}, il faudra procéder, avant de
  lancer le transfert proprement dit, à un série d'interaction avec le
  programme.
\end{note}

\section*{Conclusion}

Vous êtes maintenant armés pour découvrir le chapitre
suivant. Celui-ci va vous présenter les utilitaires composant la «
boîte à outils » d'un système \unix{}. Le bon maniement de ces outils
présuppose que vous avez correctement digéré le présent
chapitre. C'est par contre celui qui vous fera prendre conscience de
toute la puissance de la ligne de commande\footnote{Le suspense est
  tout bonnement insoutenable...}.

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "../framabook"
%%% End: 
