|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Nous allons cette fois étudier les fichiers "script", ce sera une manière de mettre un certain nombre de commandes au travail et donc de mieux les connaître. Tout d'abord, un fichier script est un simple fichier constitué d'une suite de commandes normalement trouvées dans le répertoire C, mais ces commandes peuvent être n'importe quel programme directement exécutable, à condition qu'il "rende la main" au Shell, c'est-à-dire qu'une fois exécuté, ou lancé si c'est un programme qui restera résident, on retrouve l'invite de commande du Shell et qu'on puisse continuer à envoyer d'autres commandes dans la même fenêtre, et qu'elles s'exécutent. J'appelle ces programmes des programmes "bien élevés". Bien élevé Exemple :
La commande "echo" est bien élevée. En fait, les programmes qui finissent une tâche avant qu'on ne demande autre chose, sont en général par définition bien élevés, ils rendent la main au Shell après avoir fait ce que l'on demandait ; il y en a d'à moitié bien élevés qui demandent un retour de chariot pour faire réapparaître l'invite de commande. C'est parmi les programmes qui fonctionnent, en permanence que l'on trouve les programmes mal élevés. Mal élevé Un exemple de programme intéressant mais mal élevé : PerfMon. Vous le trouverez sur votre disquette Extras 1.3, tiroir "Tools". Imaginons que vous l'ayez copié dans le répertoire "System" de votre Workbench 1.3, faisons :
Vous voyez apparaître une petite fenêtre dans laquelle sont données en permanence des informations sur le fonctionnement du système : temps d'occupation du processeur, mémoire disponible. Mais votre fenêtre Shell est bloquée ; vous pouvez y écrire ce que vous voulez, cela s'affiche, mais rien ne se passe. Ce n'est que lorsque vous aurez cliqué dans le gadget de fermeture de PerfMon que l'AmigaShell essaiera d'interpréter et d'exécuter ce que vous avez tapé. La plupart du temps d'ailleurs, cela se soldera par un message :
Un exemple de programme bien élevé (c'est un programme du domaine public) : VirusX. Imaginons que vous l'ayez mis dans votre tiroir "Utilities", faisons :
La micro-fenêtre de VirusX apparaît dans le haut de l'écran, le programme est là, il surveille en permanence toute disquette introduite dans le lecteur, mais aussitôt chargé, il rend la main au Shell et nous retrouvons notre familier :
Il y a des programmeurs qui vont rugir et donner d'excellentes raisons techniques pour que leurs programmes soient "mal élevés". A ceci j'oppose une réponse double bien que simple :
Créons un fichier script Pour créer un tel fichier, que nous appellerons par exemple "Toto", juste pour faire original, nous envoyons :
Une fenêtre s'ouvre, intitulée "Ed 1.14" (ou une autre version le cas échéant), et au bas de laquelle nous lisons en rouge : "Creating new file". S'il avait existé dans le répertoire racine de notre disquette WB1.3 un fichier nommé "Toto", son contenu aurait été affiché, à moins qu'il ne s'agisse d'un fichier binaire, auquel cas la fenêtre d'Ed se serait refermée immédiatement, en laissant le message : "File contains binary". Bon, dans le haut de notre fenêtre d'Ed, tapons :
Après quoi pressons la touche "Esc", il apparaît un astérisque dans le bas de la fenêtre, tapons "x", ce qui donne à Ed l'ordre d'écrire dans le fichier "Toto" ce que nous venons de taper, referme la fenêtre d'Ed et rend la main au CLI. Vérification Pour vérifier l'existence de notre fichier "Toto", tapons :
Quand vous avez fini, remettez Toto dans son état initial en tapant :
A présent nous allons faire fonctionner ce fichier, grâce à la commande "Execute". Mais tout d'abord, je vous demande de faire soit :
Soit :
Ceci permettra de taper "x" plutôt qu'execute qui est trop fatigant à mon goût. Toujours une copie ! Remarques :
Ceci fait, tapons :
...et le système, après une formule de politesse, nous donne de l'information sur la mémoire disponible, sur la place disponible sur la disquette et sur les gestionnaires activés, et finalement nous resalue aimablement. Script = Programme Les fichiers script ne sont autres que de petits programmes constitués de commandes qui s'exécutent en série. L'exemple type en est la fameuse startup-sequence qui, au démarrage du système, le met en état d'être utilisé plus ou moins convivialement selon ce qu'elle contient et ce qu'elle met en action. Ce n'est pas fini ! Faisons :
"Execute" n'a pas trouvé "Toto" dans le répertoire courant. Essayons en donnant au système le "chemin" complet (path) :
Ou :
Ou :
Ou :
Ou enfin :
Et tout cà marche. La répétition est l'âme de l'enseignement. Si vous ne voyez pas précisément pourquoi toutes ces syntaxes sont équivalentes, allez relire les articles suivants : Se déplacer dans les répertoires d'AmigaDOS avec le CLI et Les fichiers, unités et assignations sur AmigaOS 1.x. Si vous l'avez vu sans hésiter, vous avez de nouveau droit à un Yop fraise. A la fin de l'article, vous serez malade comme un chien, à moins que par chance vous n'aimiez pas le Yop fraise. De plus en plus fort Faisons :
...et çà marche. Un fichier de commandes placé dans le répertoire S: peut être appelé de partout par la commande Execute. Et pour couronner le tout :
Ou :
Ou encore :
Nous avons ajouté au fichier "Toto" l'attribut "s" qui lui donne une qualification complète de fichier script. Faisons :
...et Toto s'exécute devant nos yeux qui devraient raisonnablement en être éblouis. Un fichier de commandes, muni de l'attribut "s" et situé dans le répertoire S: est exécutable de partout, rien qu'en tapant son nom. En d'autres termes, il jouit des mêmes propriétés qu'une commande du répertoire C:.
|