tuteurs.ens.fr/unix/shell/presentation.tml

198 lines
5.4 KiB
Text
Raw Normal View History

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html
PUBLIC "-//ENS/Tuteurs//DTD TML 1//EN"
"tuteurs://DTD/tml.dtd">
<html>
<head>
<title>Pr<50>sentation</title>
</head>
<body>
<h1>Pr<50>sentation du shell</h1>
<h2><a name="etats">Les deux <20>tats du shell</a>
</h2>
<p>
Le shell, comme le normalien, ne conna<6E>t que deux <20>tats<74>:
</p>
<ul>
<li> le travail<69>;</li>
<li> l'inactivit<69>.</li>
</ul>
<p>
Le shell, une fois lanc<6E>, est inactif<69>: il attend qu'on lui donne
des ordres. Quand on lui en donne un, il l'ex<65>cute<74>; et quand il a
termin<EFBFBD>, il retourne <20> son <20>tat d'inactivit<69>, en attente d'un nouveau
commandement.
</p>
<p>
Quand le shell est inactif, il affiche une <em>invite</em>
(<em>prompt</em> en anglais), qui ressemble <20> cela<6C>:
</p>
<pre><span class="prompt">chaland ~ $</span></pre>
<p>
Un curseur, parfois clignotant, indique que le shell attend que vous lui
tapiez des instructions.
</p>
<h2><a name="path">Comment le shell trouve-t-il les commandes<65>?</a>
</h2>
<h3>L'ordre de recherche</h3>
<p>
J'ai l'habitude de taper des <a href="commande.html">commandes</a> dans
le shell, et je vois qu'il r<>agit. Mais comment comprend-il ce que je
veux faire<72>?
</p>
<p>
Prenons un cas simple. Je tape la commande <code>bonjour</code> <20>
l'invite (<em>prompt</em>) du shell. Il va chercher <20> plusieurs endroits
ce que j'entends par l<><6C>:
</p>
<ol>
<li> d'abord, il va se demander si <code>bonjour</code> n'est pas une de
ses commandes int<6E>gr<67>es<65>; si c'est le cas, il l'ex<65>cute
directement, sinon il passe <20> l'<27>tape suivante<74>;</li>
<li> ensuite, il va lire le contenu d'une <a
href="variable.html">variable</a>, qui s'appelle <code>PATH</code>, et
qui indique le <20><>chemin<69><6E> o<> trouver les commandes que l'on
appelle. Par exemple, si la variable PATH contient les
r<EFBFBD>pertoires<EFBFBD>:
<ul>
<li> <code>/usr/bin</code> </li>
<li> <code>/bin</code> et </li>
<li> <code>/home/toto/bin</code>,</li>
</ul>
alors le shell va chercher successivement les commandes<65>:
<ul>
<li> <code>/usr/bin/bonjour</code>,</li>
<li> <code>/bin/bonjour</code> et </li>
<li> <code>/home/toto/bin/bonjour</code><3E>;</li>
</ul></li>
<li> enfin, s'il ne trouve la commande dans aucun des r<>pertoires
r<EFBFBD>f<EFBFBD>renc<EFBFBD>s par le <code>PATH</code>, il va renvoyer un message d'erreur
en disant que d<>sol<6F>, il ne voit pas ce que l'on entend par
<code>bonjour</code>. Exemple<6C>:
<pre>
<span class="prompt">chaland ~ $</span> bonjour
bonjour: Command not found</pre> </li>
</ol>
<p> La variable <code>PATH</code> consiste en une liste de r<>pertoires
s<EFBFBD>par<EFBFBD>s par des <20><><code>:</code><3E><>. Si vous voulez voir <20> quoi
ressemble votre PATH, tapez<65>:
</p>
<pre>
<span class="prompt">chaland ~ $</span> echo $PATH</pre>
<h3><a name="builtins">Les commandes internes</a></h3>
<p>
Certaines commandes du shell ne sont pas des programmes mais des
commandes <em>internes</em> (<em>builtins functions</em>). Comme nous
l'avons vu, elles sont directement reconnues et ex<65>cut<75>es par le shell.
Un exemple de commande interne est <code>cd</code><3E>; elle modifie
le r<>pertoire courant du shell.
</p>
<div class="attention">
<p>
Attention<EFBFBD>: si vous cr<63>ez un script (c'est-<2D>-dire un programme
<EFBFBD>crit en langage shell) qui utilise <code>cd</code>, il ne modifie pas
le r<>pertoire courant du shell qui lance ce script, mais celui d'un
shell qui est cr<63><72> <20> l'occasion de l'ex<65>cution de ce script, et qui
meurt <20> la fin de cette ex<65>cution.</p>
<p> Exemple<6C>: je cr<63>e un script <code>aller</code> qui contient les
lignes suivantes<65>: </p>
<pre>
#! /bin/sh
cd $*</pre>
<p>
Nous aurons alors<72>:
</p>
<pre>
<span class="prompt">chaland ~ $</span> aller toto
<span class="prompt">chaland ~ $</span> cd toto
<span class="prompt">chaland ~/toto $</span></pre>
</div>
<h2><a name="prog">Quels programmes utilisent le langage du shell<6C>?</a></h2>
<h3>Les scripts shell</h3>
<p>
La r<>p<EFBFBD>tition de commandes complexes en ligne de commande du shell est
rapidement fastidieuse<73>; aussi est-il tr<74>s pratique de conna<6E>tre
les bases de la programmation de scripts shell. Les scripts servent <20>
automatiser ou syst<73>matiser des t<>ches.
</p>
<h3>Le script <code>.profile</code></h3>
<p>
Il existe un script sp<73>cial, qui est ex<65>cut<75> au moment o<> on se connecte. Ce
script est contenu dans le fichier <code>$HOME/.profile</code>. C'est ce
fichier qui vous dit s'il y a de nouveaux messages dans forum, si vous avez
du courrier, etc.
</p>
<p>
Ce fichier est normalement mis <20> jour automatiquement par les scripts de la
config conscrits. Il est n<>anmoins possible de le modifier pour changer des
options.
</p>
<h3>Le script <code>.xinitrc</code></h3>
<p> Il existe encore le script <code>.xinitrc</code>, qui lance X<>;
X<EFBFBD>est le gestionnaire de fen<65>tres classique sous Unix.
</p>
<h3>Cr<43>er ses propres scripts</h3>
<p>
Le nombre de scripts possibles est illimit<69><74>; vous pouvez en cr<63>er
autant que vous voulez, selon vos besoins<6E>: c'est ainsi que l'on
personnalise son syst<73>me et qu'on l'adapte <20> ses exigences, plut<75>t que
l'inverse. Pour en savoir plus sur la programmation en shell, consultez
2005-09-08 01:00:03 +02:00
les pages consacr<63>es <20> la <a href="script.html">programmation de scripts
en shell</a>. Ou bien vous pouvez revenir <20> la <a href="index.html">page
centrale sur le shell</a>, d'o<> vous pourrez vous orienter vers d'autres
parties du cours.
</p>
<div class="metainformation">
Bas<EFBFBD> sur un polycopi<70> de Roberto Di Cosmo, Xavier Leroy et Damien
Doligez.
Modifications<EFBFBD>: Nicolas George, Baptiste M<>l<EFBFBD>s.
Derni<EFBFBD>re modification le <date value="$Date: 2007-07-17 10:03:44 $"
/>.
</div>
</body>
</html>