Bonjour à tous,
Ce post fait suite à celui-ci mais comme le pb ne vient plus du makefile…
Mon problème initial :
A partir des fichiers xml du “Guide avancé d’écriture des scripts Bash”, je voulais générer les fichiers html puis le pdf de leur dernière traduction française…
Après des soucis (résolus) de makefile, maintenant quand je fais mon :
j’obtiens des tonnes d’autres erreurs liées aux fichiers xml :
[code]Version = 6.0.21
mkdir -p /home/int13h/ABS-6.0.21
xsltproc --xinclude --nonet -stringparam profile.condition html
-stringparam profile.attribute “standalone” -stringparam profile.value “no”
-stringparam chunk.quietly 0
-stringparam base.dir /home/int13h/ABS-6.0.21/
stylesheets/abs-chunked.xsl abs-book.xml
abs-part1.xml:13: parser error : Opening and ending tag mismatch: anchor line 13 and para
^
abs-part1.xml:30: parser error : Opening and ending tag mismatch: para line 13 and partintro
^
warning: failed to load external entity "ex1a.sh"
abs-part1.xml:293: parser error : Failure to process entity ex1a
&ex1a;
^
abs-part1.xml:293: parser error : Entity ‘ex1a’ not defined
&ex1a;
^
abs-part1.xml:311: parser error : Opening and ending tag mismatch: anchor line 311 and para
* * *
^
abs-part1.xml:379: parser error : Opening and ending tag mismatch: anchor line 313 and para
^
abs-part1.xml:606: parser error : Opening and ending tag mismatch: para line 313 and chapter
^
abs-part1.xml:609: parser error : Opening and ending tag mismatch: para line 311 and part
Etc, etc…[/code]
Et là, j’ai connais strictement rien en XML !!!
Voici pour info, le fichier incriminé :
[code]<?xml version="1.0" encoding="ISO-8859-1"?>
<epigraph>
<para>Script: <emphasis>A writing; a written
document. [Obs.]</emphasis></para>
<para>--<emphasis>Webster's Dictionary</emphasis>, 1913 ed.</para>
</epigraph>
<para>Le shell est un interpréteur de commandes. Plus qu'une simple couche
isolante entre le noyau du système d'exploitation et l'utilisateur, il
est aussi un langage de programmation puissant. Un programme shell,
appelé un <firstterm>script</firstterm>, est un outil facile à utiliser
pour construire des applications en <quote>regroupant</quote> des appels
système, outils, utilitaires et binaires compilés. Virtuellement, le
répertoire entier des commandes UNIX, des utilitaires et des outils est
disponible à partir d'un script shell. Si ce n'était pas suffisant, les
commandes shell internes, telles que les contrôles de tests et de
boucles, donnent une puissance et une flexibilité supplémentaires aux
scripts. Les scripts shell conviennent particulièrement bien pour les
tâches d'administration du système et pour d'autres routines répétitives
ne réclamant pas les particularités d'un langage de programmation structuré
complet.</para>
<epigraph>
<para>Aucun langage de programmation n'est parfait. Il n'existe même pas
un langage meilleur que d'autre ; il n'y a que des langages en
adéquation ou peu conseillés pour des buts particuliers.</para>
<para>-- Herbert Mayer</para>
</epigraph>
<para>Une connaissance fonctionnelle de la programmation shell est
essentielle à quiconque souhaite devenir efficace en administration de
système, même pour ceux qui ne pensent pas avoir à écrire un
script un jour. Pensez qu'au démarrage de la machine Linux, des scripts
shell du répertoire <filename class="directory">/etc/rc.d</filename> sont
exécutés pour restaurer la configuration du système et permettre la mise
en fonctionnement des services. Une compréhension détaillée de ces
scripts de démarrage est importante pour analyser le comportement d'un
système, et éventuellement le modifier.
</para>
<para>Écrire des scripts shell n'est pas difficile à apprendre car, d'une part, les
scripts peuvent être construits par petites sections et, d'autre part,
il n'y a qu'un assez petit nombre d'opérateurs et d'options
<footnote><para>Ces opérateurs et options sont appelés <link
linkend="builtinref">commandes intégrées</link>, c'est-à-dire des
fonctionnalités internes au shell.</para></footnote>
spécifiques au shell à connaître. La syntaxe est simple et directe,
similaire à une suite d'appels de différents utilitaires en ligne de
commande et il n'existe que peu de <quote>règles</quote> à apprendre.
La plupart des petits scripts fonctionnent du premier coup et le
débogage, même des plus longs, est assez simple.</para>
<para>
<blockquote>
<literallayout>
In the 1970s, the <wordasword>BASIC</wordasword> language enabled anyone reasonably computer proficient
to write programs on an early generation of microcomputers. Decades later, the <wordasword>Bash</wordasword>
scripting language enables anyone with a rudimentary knowledge of Linux or UNIX to do the same
on much more powerful machines.
</literallayout>
</blockquote>
</para>
<para>Un script shell est une méthode <quote>rapide et sale</quote> pour
prototyper une application complexe. Avoir même un sous-ensemble limité
de fonctionnalités dans un script shell est souvent une
première étape utile lors d'un projet de développement. De cette façon,
la structure de l'application peut être testée et les problèmes majeurs
trouvés avant d'effectuer le codage final en <firstterm>C</firstterm>,
<firstterm>C++</firstterm>, <firstterm>Java</firstterm>, <link
linkend="perlref">Perl</link> ou <firstterm>Python</firstterm>.
</para>
<para>La programmation shell ramène à la philosophie classique des UNIX,
de découper des projets complexes en sous-tâches plus simples
et d'assembler des composants et les utilitaires.
Beaucoup considèrent que cette approche de la résolution de problème
est meilleure ou, du moins, plus abordable que l'utilisation de langages de
nouvelle génération puissamment intégrés comme <firstterm>Perl</firstterm>, qui
essaient de tout faire pour tout le monde mais au prix de vous forcer à
changer votre processus de réflexion pour vous adapter à l'outil.</para>
<para>D'après <link linkend="mayerref">Herbert Mayer</link>,
<quote>un langage utile doit comprendre des tableaux, des pointeurs et un
mécanisme générique pour construire des structures de données.</quote>
Suivant ces critères, les langages des scripts shell ne sont pas
<quote>utiles</quote>. Enfin, peut-être que si...</para>
<sidebar>
<para>Quand ne pas utiliser les scripts shell
<itemizedlist>
<listitem>
<para>pour des tâches demandant beaucoup de ressources et
particulièrement lorsque la rapidité est un facteur (tri, hachage,
récursion
<footnote><para>Bien que la <link linkend="recursionref0">récursion
<emphasis>est</emphasis> possible dans un script shell</link>,
elle tend à être lente et son implémentation est souvent le
résultat d'un <link linkend="fiboref">code sale</link>.</para></footnote>
...) ;</para>
</listitem>
<listitem>
<para>pour des procédures impliquant des opérations mathématiques
nombreuses et complexes, spécialement pour de l'arithmétique
à virgule flottante, des calculs à précision arbitraire ou des
nombres complexes (optez plutôt pour le <firstterm>C++</firstterm>
ou le <firstterm>FORTRAN</firstterm> dans ce cas) ;</para>
</listitem>
<listitem>
<para>pour une portabilité inter-plateformes (utilisez le
<firstterm>C</firstterm> ou <firstterm>Java</firstterm>
à la place) ;</para>
</listitem>
<listitem>
<para>pour des applications complexes où une programmation
structurée est nécessaire (typage de variables, prototypage de
fonctions, etc.) ;</para>
</listitem>
<listitem>
<para>pour des applications critiques sur lesquelles vous misez
l'avenir de votre société ;</para>
</listitem>
<listitem>
<para>pour des situations où la <emphasis>sécurité</emphasis> est
importante, où vous avez
besoin de garantir l'intégrité de votre système et de vous protéger
contre les intrusions et le vandalisme ;</para>
</listitem>
<listitem>
<para>pour des projets consistant en de nombreux composants avec des
dépendances inter-verrouillées ;</para>
</listitem>
<listitem>
<para>lorsque des opérations importantes sur des fichiers sont
requises (<firstterm>Bash</firstterm> est limité à un accès
fichier en série, ligne par ligne, ce qui est particulièrement
maladroit et inefficace) ;</para>
</listitem>
<listitem>
<para>si le support natif des tableaux multidimensionnels est
nécessaire ;</para>
</listitem>
<listitem>
<para>si vous avez besoin de structures de données, telles que des
listes chaînées ou des arbres ;</para>
</listitem>
<listitem>
<para>si vous avez besoin de générer ou de manipuler des graphiques
ou une interface utilisateur (<acronym>GUI</acronym>) ;</para>
</listitem>
<listitem>
<para>lorsqu'un accès direct au matériel est nécessaire ;</para>
</listitem>
<listitem>
<para>lorsque vous avez besoin d'accéder à un port, à un
<link linkend="socketref">socket</link>
d'entrée/sortie ;</para>
</listitem>
<listitem>
<para>si vous avez besoin d'utiliser des bibliothèques ou une
interface propriétaire ;</para>
</listitem>
<listitem>
<para>pour des applications propriétaires, à sources fermées (les
sources des shells sont forcément visibles par tout le monde).
</para>
</listitem>
</itemizedlist>
</para>
<para>Dans l'un des cas ci-dessus, considérez l'utilisation
d'un langage de scripts plus puissant, peut-être <firstterm>Perl</firstterm>,
<firstterm>Tcl</firstterm>, <firstterm>Python</firstterm>,
<firstterm>Ruby</firstterm>, voire un langage compilé
tel que <firstterm>C</firstterm>, <firstterm>C++</firstterm> ou
<firstterm>Java</firstterm>. Même dans ce cas, prototyper l'application
avec un script shell peut toujours être une étape utile au développement.
</para>
<para id="bashdef">Nous utiliserons <acronym>Bash</acronym>, un acronyme
pour <quote>Bourne-Again shell</quote> et un calembour sur le désormais
classique <firstterm>Bourne</firstterm> shell de
Stephen Bourne. Bash est devenu un standard <foreignphrase>de facto
</foreignphrase> pour la programmation de scripts sur la plupart des
systèmes UNIX. La plupart des principes discutés dans ce livre s'appliquent
également à l'écriture de scripts avec d'autres shells tels que le
<firstterm>Korn Shell</firstterm>, dont dérivent certaines des
fonctionnalités de Bash,
<footnote><para>Beaucoup de fonctionnalités de
<firstterm>ksh88</firstterm>, et même quelques unes de la version mise à
jour <firstterm>ksh93</firstterm>, ont été intégrées à Bash.
</para></footnote>
, le <firstterm>shell C</firstterm> et ses variantes (notez que la
programmation en <firstterm>shell C</firstterm>
n'est pas recommandée à cause de certains problèmes inhérents, comme indiqué
en octobre 1993 sur un <ulink
url="http://www.etext.org/Quartz/computer/unix/csh.harmful.gz">message
Usenet</ulink> par Tom Christiansen).</para>
<para>Ce qui suit est un tutoriel sur l'écriture de scripts shell. Il
est en grande partie composé d'exemples illustrant différentes fonctionnalités
du shell. Les scripts en exemple ont été testés, autant que
possible, et certains d'entre eux peuvent même être utiles dans la vraie
vie. Le lecteur peut jouer avec le code des exemples dans l'archive des
sources (<filename>nom_script.sh</filename> ou
<filename>nom_script.bash</filename>),
<footnote><para>Par convention, les scripts shell écrits par
l'utilisateur, compatibles avec le shell Bourne, sont nommés avec l'extension
<filename>.sh</filename>. Les scripts système, tels que
ceux trouvés dans <filename class="directory">/etc/rc.d</filename>,
ne suivent pas cette nomenclature.</para></footnote>
leur donner le droit d'<firstterm>exécution</firstterm>
(<userinput>chmod u+rx nom_du_script</userinput>) et les
exécuter pour voir ce qu'il se passe.
Si les <ulink
url="http://abs.traduc.org/abs-fr/abs-guide-latest.tar.bz2">sources</ulink>
ne sont pas disponibles, alors copiez/collez
à partir de la version <ulink
url="http://abs.traduc.org/abs-fr/abs-6.0-fr-html.tar.bz2">HTML</ulink>
ou <ulink url="http://abs.traduc.org/abs-fr/abs-6.0.pdf">PDF</ulink>.
Sachez que certains scripts
présentés ici introduisent des fonctionnalités avant qu'elle ne soient
expliquées et que ceci pourrait réclamer du lecteur de lire
temporairement plus avant pour des éclaircissements.</para>
<para>Sauf mention contraire, l'<ulink
url="mailto:thegrendel.abs@gmail.com">auteur</ulink> de ce livre a écrit
les scripts d'exemples qui suivent.</para>
<epigraph>
<para>His countenance was bold and bashed not.</para>
<para>--Edmund Spenser</para>
</epigraph>
Lancement avec un #!
<epigraph>
<para>La programmation shell est un juke box des années 50...</para>
<para>-- Larry Wall</para>
</epigraph>
<para>Dans le cas le plus simple, un script n'est rien de plus qu'une liste
de commandes système enregistrées dans un fichier. À tout le moins, cela
évite l'effort de retaper cette séquence
particulière de commandes à chaque fois qu'elle doit être appelée.</para>
<example id="ex1">
<title><firstterm>cleanup</firstterm> : Un script pour nettoyer les journaux de
trace dans /var/log </title> <programlisting>&ex1;</programlisting>
</example>
<para>Il n'y a rien d'inhabituel ici, seulement un ensemble de commandes
qui pourraient tout aussi bien être appelées l'une après l'autre à
partir de la ligne de commande sur la console ou un terminal.
Mais les avantages de les placer dans un script
vont bien au-delà du simple fait ne pas avoir à les retaper
continuellement. C'est que le script devient ainsi un
<emphasis>programme</emphasis> -- ou un
<emphasis>outil</emphasis> --, facile à modifier et à
personnaliser pour une application particulière.</para>
<example id="ex1a">
<title><firstterm>cleanup</firstterm> : Un script de nettoyage amélioré</title>
<programlisting>&ex1a;</programlisting>
</example>
<para>Maintenant, cela commence à ressembler à un vrai script. Mais nous
pouvons aller encore plus loin...</para>
<example id="ex2">
<title><firstterm>cleanup</firstterm> : Une version améliorée et généralisée
des scripts précédents</title>
<xi:include xmlns:xi=“http://www.w3.org/2003/XInclude” parse=“text” href=“ex2.sh”/>
<para>Comme vous pouvez ne pas vouloir supprimer toutes les traces système,
cette variante du script conserve la dernière section des traces
intacte. Vous découvrirez en permanence de nouvelles façons pour
affiner des scripts précédemment écrits et améliorer ainsi leur efficacité.
</para>
<para><anchor id="shabangref">* * *</para>
<para><anchor id="magnumref">Le <firstterm>
<indexterm><primary>sha-bang</primary></indexterm>sha-bang</firstterm>
(<token><indexterm><primary>#!</primary></indexterm>#!</token>)
<footnote><para>Également appelé
<firstterm>she-bang</firstterm> et de <firstterm>sh-bang</firstterm>.
Ceci est dérivé de la concaténation des caractères
<token>#</token> (en anglais, <firstterm>sharp</firstterm>) et
<token>!</token> (en anglais, <firstterm>bang</firstterm>).</para>
</footnote>
en en-tête de ce fichier indique à votre système que ce
fichier est un ensemble de commandes pour l'interpréteur indiqué.
<anchor id="magnumref"/>Les caractères <token>#!</token> sont codés sur
deux octets
<footnote>
<para>Certains systèmes UNIX (ceux basés sur 4.2BSD)
prétendent coder ce nombre magique sur quatre octets, réclamant une espace
après le <token>!</token>,
<userinput>#! /bin/sh</userinput>. <ulink
url="http://www.in-ulm.de/~mascheck/various/shebang/#details">
D'après Sven Mascheck</ulink>, c'est probablement un mythe.</para>
</footnote>
<indexterm>
<primary>nombre magique</primary>
</indexterm>
et correspondent en fait à un <firstterm>nombre magique</firstterm>,
un marqueur spécial qui désigne
un type de fichier, ou dans ce cas, un script shell exécutable (lancez
<userinput>man magic</userinput> pour
plus de détails sur ce thème fascinant). Tout de suite après le
<emphasis>sha-bang</emphasis> se trouve un <firstterm>chemin</firstterm>.
C'est le chemin vers le programme qui interprète les commandes de ce
script, qu'il soit un shell, un langage de programmation ou un utilitaire.
Ensuite, cet interpréteur de commande exécute les commandes du
script, en commençant au début (la ligne suivant immédiatement
celle avec le <token>#!</token>), en ignorant les commentaires.
<footnote>
<para>La ligne <token>#!</token> d'un script shell est la première
chose que l'interpréteur de commande
(<command>sh</command> ou <command>bash</command>) voit. Comme
cette ligne commence avec un <token>#</token>, il sera
correctement interprété en tant que commentaire lorsque
l'interpréteur de commandes exécutera finalement le script. La
ligne a déjà été utilisé pour appeler l'interpréteur de
commandes.</para>
<para>En fait, si le script inclut une ligne <token>#!</token>
<emphasis>supplémentaire</emphasis>, alors
<command>bash</command> l'interprètera comme un commentaire.
<programlisting>#!/bin/bash
echo "Partie 1 du script."
a=1
#!/bin/bash
Ceci ne lance pas un nouveau script.
echo "Partie 2 du script."
echo $a # Valeur de $a est toujours 1.
</footnote>
</para>
<para><programlisting>#!/bin/sh
#!/bin/bash
#!/usr/bin/perl
#!/usr/bin/tcl
#!/bin/sed -f
#!/usr/awk -f
<para>Chacune des lignes d'en-tête du script ci-dessus appelle un
interpréteur de commande différent, qu'il soit
<filename>/bin/sh</filename>, le shell par défaut
(<command>bash</command> dans un système Linux) ou autre chose.</para>
<footnote>
<para>Ceci permet des tours de passe-passe :</para>
<para><programlisting>#!/bin/rm
Script se supprimant lui-même.
Rien de plus ne semble se produire lorsque vous le lancez… sauf
#+ que le fichier disparaît.
QUELQUECHOSE=85
echo “Cette ligne ne s’affichera jamais.”
exit $QUELQUECHOSE # Peu importe. Le script ne se terminera pas ici.
# Tester un echo $? après la fin du script.
# Vous obtiendrez 0, au lieu de 85.
<para>De la même manière, essayez de lancer un fichier
<filename>README</filename> avec un <userinput>#!/bin/more</userinput>
après l'avoir rendu exécutable. Le résultat est un fichier de
documentation s'affichant lui-même. (Un <link linkend="heredocref">document
en ligne</link> utilisant <link linkend="catref">cat</link> est certainement
une meilleure solution — voir <xref linkend="ex71"/>).</para>
</footnote>
<para>Utiliser <userinput>#!/bin/sh</userinput>, par défaut Bourne Shell
dans la plupart des variantes commerciales d'UNIX, rend le script <link
linkend="portabilityissues">portable</link> aux machines non-Linux,
malheureusement <link linkend="binsh">en faisant le sacrifice des
fonctionnalités spécifiques à Bash</link>. Le script se conformera néanmoins au
standard <command>sh</command> de <acronym>POSIX</acronym>
<footnote>
<para id="posix2ref"><emphasis role="strong">P</emphasis>ortable
<emphasis role="strong">O</emphasis>perating
<emphasis role="strong">S</emphasis>ystem <emphasis
role="bold">I</emphasis>nterface, an attempt to
standardize UNI<emphasis role="strong">X</emphasis>-like
OSes (NdT : interface de systèmes d'exploitation portables, un essai
pour standardiser les UNIX). Les spécifications POSIX sont disponibles
sur le <ulink
url="http://www.opengroup.org/onlinepubs/007904975/toc.htm">site Open
Group</ulink>.</para>
</footnote>
</para>
<para>Notez que le chemin donné à <quote>sha-bang</quote> doit être correct,
sinon un message d'erreur — habituellement <quote>Command
not found</quote> — sera le seul résultat du lancement du
script.
<footnote><para>Pour éviter ce risque, un script peut commencer
avec une ligne <firstterm>sha-bang</firstterm>,
<link linkend="envv2ref">#!/bin/env bash</link>. Ceci pourrait être
utile sur les machines UNIX où <firstterm>bash</firstterm> n'est
pas dans <filename
class="directory">/bin</filename></para></footnote>
</para>
<para><token>#!</token> peut être omis si le script consiste seulement en
un ensemble de commandes système génériques, sans utiliser de directives
shell interne. Le second exemple, ci-dessus, requiert le
<token>#!</token> initial car la ligne d'affectation des variables,
<userinput>lignes=50</userinput>, utilise une construction spécifique au
shell.
<footnote>
<para>Si <firstterm>Bash</firstterm> est votre shell par défaut, alors
<token>#!</token> n'est pas nécessaire. Par contre, si vous lancez
un script à partir d'un shell différent, comme
<firstterm>tcsh</firstterm>, alors vous <emphasis>aurez</emphasis>
besoin de <token>#!</token>.</para>
</footnote>
Notez encore que <userinput>#!/bin/sh</userinput> appelle
l'interpréteur shell par défaut, qui est <filename>/bin/bash</filename>
sur une machine Linux.</para>
<tip>
<para>Ce tutoriel encourage une approche modulaire de la construction
de script. Prenez note et collectionnez les astuces sous forme de
<quote>blocs simples</quote> de code pouvant être utiles pour de futurs
scripts. À la longue, vous obtiendrez une bibliothèque assez
étendue de routines bien conçues. À titre d'exemple, le début du script
suivant teste si le script a été appelé avec le bon nombre de
paramètres.</para>
<para><programlisting>E_MAUVAIS_ARGS=85
parametres_scripts="-a -h -m -z"
-a = all, -h = help, etc.
if [ $# -ne $Nombre_arguments_attendus ]
then
echo “Usage: basename $0 $parametres_scripts”
basename $0 est le nom du fichier contenant le script.
exit $E_MAUVAIS_ARGS
fi
<para>Très souvent, vous écrirez un script pour réaliser une tâche
particulière. Le premier script de ce chapitre en est un exemple. Plus
tard, il pourrait vous arriver de généraliser le script pour effectuer
d'autres tâches similaires. Remplacer les constantes littérales
(<quote>codées en dur</quote>) par des variables est une étape dans cette
direction, comme le fait de remplacer les blocs de code répétitifs par
des <link linkend="functionref">fonctions</link>.</para>
</tip>
<sect1 id="invoking">
<title>Appeler le script</title>
<para>Après avoir écrit le script, vous pouvez l'appeler avec
<userinput>sh nom_script</userinput>
<footnote>
<para>Attention : appeler un script <firstterm>Bash</firstterm>
avec <userinput>sh nom_script</userinput> désactive les
extensions spécifiques à Bash, et donc le script peut ne pas
fonctionner.</para>
</footnote>,
ou avec <userinput>bash nom_script</userinput> (il n'est
pas recommandé d'utiliser <userinput>sh nom_script</userinput>
car cela désactive la lecture de <link
linkend="stdinoutdef"><filename>stdin</filename></link> à l'intérieur
du script). Il est bien plus aisé de rendre le script directement
exécutable avec un <link linkend="chmodref">chmod</link>.
<variablelist>
<varlistentry>
<term>Soit</term>
<listitem>
<para><userinput>chmod 555 nom_script</userinput> (donne les
droits de lecture/exécution à tout le monde)
<footnote><para>Pour pouvoir être lancé, un script a besoin
du droit de <emphasis>lecture</emphasis>
(<firstterm>read</firstterm>) en plus de celui
d'exécution, car le shell a besoin de le lire.
</para></footnote>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>soit</term>
<listitem>
<para><userinput>chmod +rx nom_script</userinput> (donne les
droits de lecture et d'exécution à tout le monde)</para>
<para><userinput>chmod u+rx nom_script</userinput> (donne
les droits de lecture et d'exécution seulement à son propriétaire)</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>Maintenant que vous avez rendu le script exécutable, vous pouvez
le tester avec <userinput>./nom_script</userinput>
<footnote><para>Pourquoi ne pas simplement appeler le script avec
<userinput>nom_script</userinput> ? Si le répertoire où vous vous
trouvez (<link linkend="pwdref">$PWD</link>) est déjà celui où se
trouve <filename>nom_script</filename>, pourquoi cela ne
fonctionne-t'il pas ? Cela échoue parce que, pour des raisons de
sécurité, le répertoire courant (<filename class="directory">./</filename>)
n'est pas inclus par défaut
dans le <link linkend="pathref">$PATH</link> de l'utilisateur. Il est
donc nécessaire d'appeler le script de façon explicite dans le
répertoire courant avec <userinput>./nom_script</userinput>.
</para></footnote>.
S'il commence par une ligne <quote>sha-bang</quote>, appeler le script
appelle le bon interpréteur de commande.</para>
<para>Enfin, après les tests et le débogage final, vous
voudrez certainement le déplacer dans <filename
class="directory">/usr/local/bin</filename> (en tant que
<firstterm>root</firstterm>, bien
sûr), pour le rendre utilisable par vous et par tous les autres
utilisateurs du système. Le script pourra alors être appelé en tapant
simplement <command>nom_script</command> <keycap>[ENTER]</keycap> sur
la ligne de commande.</para>
</sect1> <!-- Invoking the script -->
<sect1 id="prelimexer">
<title>Exercices préliminaires</title>
<orderedlist>
<listitem>
<para>Les administrateurs système écrivent souvent des scripts pour
automatiser certaines tâches. Donnez quelques exemples où de tels
scripts sont utiles.</para>
</listitem>
<listitem>
<para>Écrivez un script qui, lors de son exécution, donne
<link linkend="dateref">la date et l'heure</link>, <link
linkend="whoref">la liste de tous les utilisateurs connectés</link>
et le temps passé depuis le lancement du système (<link linkend="uptimeref">uptime</link>)
du système. Enfin, le script doit <link
linkend="ioredirref">sauvegarder cette information</link> dans un
journal.</para>
</listitem>
</orderedlist>
</sect1> <!-- Preliminary Exercises -->
[/code]
C’est à priori le même fichier qui était utilisé avant, et qui donc fonctionnait bien…
Pourquoi ces erreurs alors ?
Un spécialiste de xml peut-il m’aider, svp ?
Merci d’avance,
Eric