 |
Samedi 20 avril 2024 - 03:44 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Petit retour à l'article précédent
Dans mon article précédent, j'ai affirmé erronément qu'un fichier de commandes muni de l'attribut "S" (et de l'attribut "E", bien sûr, mais les fichiers créés par Ed en sont munis congénitalement) et logé dans le répertoire S: était exécutable de n'importe où rien qu'en tapant son nom. Strictement, c'est faux, mais quand j'ai écrit l'article, ça marchait, car je vérifie toujours le fonctionnement des exemples que je donne.
Qu'est-ce qui a bien pu se passer ? D'abord, rétablissons la vérité : un fichier de commandes, muni des attributs "S" (script) et "E" (exécutable), se comporte comme une commande du répertoire C:, c'est-à-dire s'exécute rien qu'à la frappe de son nom, quel que soit le répertoire courant, à condition qu'il soit logé dans le répertoire C: !
Quoique... l'exemple donné marche ! Retournons un moment dans le répertoire C: et examinons la commande Path. Lorsque vous tapez le nom d'une commande, par exemple Dir, AmigaDOS regarde d'abord dans le répertoire courant ; s'il ne la trouve pas, il va dans le répertoire C:.
Rappelons au passage que le répertoire C: est le répertoire "c" de la disquette de démarrage, sauf si par après on a désigné un autre répertoire comme étant C: par la commande Assign.
Souvenez-vous de l'exemple où nous avons mis quelques commandes en RAM: puis nous avons fait :
| assign C: ram: |
...ce qui nous a permis de retirer de notre unique lecteur la disquette Workbench, d'en insérer une autre, et d'utiliser les commandes logées en RAM: pour lire des fichiers ou faire des copies.
La commande Path
Venons-en à la commande Path. Elle permet de désigner des chemins aboutissant à des répertoires dans lesquels le système ira chercher des commandes qu'il n'aurait pas trouvées dans le répertoire courant, ni dans le répertoire C:.
La syntaxe est, par exemple :
| WB1.3> Path sys: s: ram: sys:system sys:utilities sys:prefs ADD |
Cette commande dit au système : si une commande que tu vas recevoir n'est ni dans le répertoire courant, ni dans C:, va donc faire un tour dans le répertoire racine de la disquette d'amorce, dans S:, dans RAM:, et dans les tiroirs sys:system, sys:utilities et sys:prefs.
Pour être super précis, il aurait même fallu dire, dans le paragraphe ci-dessus, va faire un tour dans le répertoire qui a été assigné comme répertoire sys: etc. Bon, il n'est pas question de transformer une série d'articles d'initiation en un traité (personne ne le lirait, chaque jour je tombe sur des choses qui m'ont échappé lors de la lecture des docs parce que la lecture des docs est emmerdante), mais il est tout de même bon de savoir que si quelque chose ne marche pas du premier coup comme décrit, il peut y avoir un petit piège quelque part, et qu'il faut chercher un peu. C'est d'ailleurs cette série d'accidents et de recherches qui fait qu'au bout d'un certain temps, on finit par "sentir" où ça foire.
Si au bout de ce périple le système n'a pas trouvé la commande tapée, il sort un message d'erreur :
| unknown command "ce que vous avez tapé" |
L'utilisation de Path avec cette syntaxe vous permettra d'appeler directement par leur nom, sans indiquer le chemin, les utilitaires logés dans ces tiroirs. Exemple : après avoir tapé la commande Path comme ci-dessus, les commandes...
| WB1.3> sys:system/utilities/Keytoy2000 |
Et...
| WB1.3> Keytoy2000 |
...auront le même effet. Je me demande au passage pourquoi Commodore nous fournit ce programme qui ne sert strictement à rien.
Comme il y a dans la startup-sequence du WB1.3 une ligne :
| Path sys: s: ram: add |
...un fichier script muni de l'attribut "S" s'exécute directement s'il est logé dans un de ces tiroirs, en particulier dans S:.
A tout hasard, vérifiez bien que la ligne de commande Path de votre startup-sequence comporte bien les noms (avec leurs chemins le cas échéant), de tous les répertoires dans lesquels il y a des fichiers exécutables que vous voulez pouvoir appeler rien qu'en tapant leur nom, et ceci quel que soit le répertoire courant.
Ceci fait que vous n'aurez droit à Ask que la prochaine fois.
A présent les choses sérieuses
Comme les fichiers script vont nous permettre de réaliser des commandes particulières, correspondant à nos besoins personnels, sans devoir utiliser un langage de programmation, ils méritent bien un examen un peu plus prolongé.
Commençons par un cas tout simple : nous avons vu dans un article précédent comment nous pouvions obtenir l'arborescence complète des répertoires et fichiers contenus dans un répertoire donné, par la commande :
| Dir opt A |
Pour vous rafraîchir la mémoire, faites :
|
...> cd df0: WB1.3> dir opt a |
...et votre frustration commence au moment où ce qui est en haut de la fenêtre fout le camp avant que vous n'ayez eu le temps de le lire.
Plutôt que de déployer votre réserve d'expressions colorées et plus ou moins malsonnantes, faites :
| WB1.3> dir > ram:toto opt a |
Puis, quand le lecteur a fini de grogner :
| WB1.3> more ram:toto |
On l'a déjà fait précédemment, pas de problèmes. Au lieu de ceci, faites maintenant :
| WB1.3> ed c:dm (mnémonique pour Dir-More) |
"dm" est un nom parfaitement arbitraire, le nom de votre chat ira aussi bien, surtout s'il est court (le nom, pas le chat). Tapez dans la fenêtre de Ed les deux lignes :
|
dir > ram:toto opt a more ram:toto |
Sortez d'Ed en faisant "Esc+X", il y a maintenant dans C: un fichier nommé "dm" (ou autre chose selon votre choix) auquel vous allez vous empresser d'ajouter l'attribut "S" :
| WB1.3> protect c:dm +s |
Faites maintenant :
| WB1.3> dm |
Et après un moment de patience apparaît à l'écran la fenêtre de More, qui vous permet de revoir tout le résultat de votre commande "Dir opt A" de haut en bas et de bas en haut.
Vous avez en fait créé une nouvelle commande du système.
Attention, il y a un piège : si vous modifiez votre fichier script par Ed, lorsque vous sauvez la version modifiée, Ed ne remet pas l'attribut "S" ! Il faut donc penser à refaire après chaque modification la commande :
| WB1.3> protect c:dm +s |
Sans quoi, quand vous ferez "dm" , vous aurez :
| WB1.3> dm unable to load "dm" : file is flot an object module. |
Ceci vient du fait qu'Ed a été écrit avant l'apparition de l'attribut "S" dans le Workbench 1.3, et n'a pas été modifié, sur ce point du moins.
Notre commande "dm" est surtout didactique, elle n'est pas très performante, elle n'est pas plus rapide que la suite des deux commandes qu'elle regroupe, mais elle a le mérite de nous éviter de la frappe. Pour la rendre performante, il faudrait utiliser une unité de type Pipe, qui permet de passer les données fournies par un programme , en l'occurrence Dir, à un autre programme, dans notre cas More, au fur et à mesure de leur production, sans passer par la création d'un fichier intermédiaire (notre RAM:toto) ; malheureusement, le Pipe fourni dans AmigaDOS est un peu lourd à utiliser.
Arguments et paramètres
Argument, au sens mathématique, signifie, d'après le Larousse en deux volumes de feu mon beau-père, où l'on peut admirer sur de superbes gravures l'état de la technique au début du siècle :
"Math. Quantité dont dépend une circonstance mathématique, équation, ou égalité, ou détermination."
Qu'en termes élégants ces choses-là sont dites !
En informatique, un argument d'une commande est en général une chaîne de caractères, ou nombre, qui détermine à quoi la commande va s'appliquer. Par exemple :
| WB1.3> List s: |
"s:" est un argument pour "List".
En passant, un paramètre est la plupart du temps une lettre ou un chiffre qui va modifier le comportement de la commande; exemple :
| WB1.3> type toto opt n |
"n" est le paramètre qui dit à "Type" d'afficher le contenu du fichier "toto" en numérotant les lignes.
Ces définitions sont assez arbitraires, et dans les docs américaines, leur utilisation n'obéit pas à des règles constantes. Il faut dire que nos amis américains sont en général assez peu pointilleux sur le choix des mots, ce qui rend parfois leurs docs difficiles à comprendre. Entre nous, elles valent quand même mieux que des docs françaises écrites par des polytechniciens et qui contiennent tellement d'information sous forme implicite qu'elles sont encore plus difficiles à comprendre.
Imaginons que nous souhaitions chercher dans un répertoire les fichiers munis de l'attribut "S", et lire à l'écran, par More, la liste de ces commandes, triée par ordre alphabétique (vous avez certainement déjà remarqué que List, contrairement à Dir, ne présente pas les fichiers triés par ordre alphabétique).
Nous allons créer un fichier script que nous appellerons par exemple "dx". Appelons Ed, en tapant :
| WB1.3> Ed c:dx |
Et dans la fenêtre Ed, entrons :
|
.key repertoire list > ram:liste <repertoire> nodates sort ram liste ram:ordonnee search > ram:triee ram:ordonnee #?-s--rwed#? more ram:triee |
(ceci fonctionne avec la commande "Search" de la bibliothèque Arp)
Ensuite, faites "Esc+X" pour sauver le fichier, puis bien sûr :
| WB1.3> protect c:dx +s |
Et essayons notre commande :
| WB1.3> dx s: |
Et ça donne :
Analysons
Commençons par analyser ce résultat, nous décortiquerons ensuite notre fichier script. Si nous avions fait "List df0:s", nous aurions vu qu'il y a huit fichiers, mais le fichier startup-sequence (du moins sur ma disquette Workbench 1.3) n'est pas muni de l'attribut "S". S'il en avait été muni, il serait apparu en position 8 dans notre résultat.
Les positions 1 et 3 manquent, elles correspondent simplement à l'en-tête et à la dernière ligne de l'affichage de List, et dans ces lignes il n'y a rien qui ressemble à la chaîne "-s--rwed".
Après avoir lu la suite, faites l'exercice de modifier le fichier "dm" de manière à éviter cette anomalie. Cette fois-ci, il n'y a pas de Yop fraise pour les gagnants.
Maintenant, décortiquons notre fichier "dx".
| .key répertoire |
D'abord, jamais de caractères accentués dans des commandes ou dans des noms de fichiers, AmigaDOS les traite, mais beaucoup de programmes américains ne les acceptent pas.
Quand une ligne d'un fichier script commence par un point, AmigaDOS interprète qu'il ne s'agit pas d'une commande à exécuter, mais qu'il s'agit d'instructions relatives au traitement des arguments ou paramètres. Au demeurant, pour que ce mécanisme fonctionne, il faut que la première ligne du fichier commence par un point ; il peut y en avoir d'autres plus loin.
Le mot "Key" (clé) indique le format de ce qu'il faudra aller remplacer dans le fichier "dx" par le ou les arguments ou paramètres de la commande. Dur dur. En clair, dans le cas présent, cette ligne dit à AmigaDOS : chaque fois que tu vas voir "répertoire" dans le présent fichier de commande, tu le remplaceras par "s:" (nous avions tapé dx s:).
| list > ram:liste <répertoire> nodates |
Lorsqu'AmigaDOS voit un mot entre < >, il sait que c'est un des mots-clé de la première ligne ; il va donc remplacer <répertoire> par l'argument de la commande "dx", donc dans le cas présent par "s:".
Le reste de la ligne ne doit pas vous poser de problèmes ; le résultat de la commande List est envoyé dans un fichier nommé "liste" qui se crée dans RAM:, l'option "nodates" parle d'elle-même.
| sort ram liste ram:ordonnee |
Veuillez trier par ordre alphabétique (sur la première lettre de chaque ligne) les lignes du fichier ram:liste et me mettre ça dans un fichier "ordonnee" également dans RAM: (tout ce qui se fait en RAM: va évidemment très vite, car RAM: se comporte comme un disque virtuel d'accès quasi instantané).
| search > ram:triee ram:ordonnee #?-s--rwed#? |
Veuillez parcourir le fichier ram:ordonnee, prendre chaque ligne qui contient "n'importe quoi -s--rwed n'importe quoi" et la mettre dans un fichier ram:triee.
| more ram:triee |
Pas besoin d'explication !
#?
Il est vrai que je ne vous ai jamais expliqué le truc de "#?". J'espère que vous l'avez trouvé par vous-même dans la doc, mais, juste au cas, et rapidement : certaines commandes acceptent que dans leur argument un caractère soit remplacé par "?" comme au scrabble une lettre quelconque par le pion blanc. Le signe "#" indique qu'il peut y avoir n'importe quel nombre de caractères quelconques.
- anim? représente donc anime, anima, anims, etc.
- anim#? représente anime, animera, animerez, etc.
- list #?.info donnera la liste de tous les fichiers d'icônes du répertoire courant.
- delete glup#? enlèvera tous les fichiers dont le nom commence par "glup". C'est pratique pour enlever à la fois un fichier et son icône.
Simple histoire de se faire un peu mal à la tête, essayons d'écrire une commande qui accepte un argument et un paramètre. Partons de notre commande "dx", et créons une commande "dz" qui nous listera, dans l'ordre alphabétique, les fichiers d'un répertoire, qui ont l'attribut "P" ou "S".
Voir l'encadré suivant pour ce que l'on peut taper dans Ed !
Commentaires : la mise en page en colonnes étroites du journal ne permet pas de faire de manière lisible les commentaires dans le texte du fichier, je les fais donc séparément.
Sur la syntaxe de la commande IF, voyez le manuel, et ne vous étonnez pas d'avoir à vous y reprendre plusieurs fois avant d'arriver à quelque chose. Point n'est besoin d'espérer pour entreprendre, ni de réussir pour persévérer. Le premier bout du programme s'assure que vous avez demandé de sortir les fichiers munis de l'attribut "S" ou "P", et pas autre chose, sinon il vous envoie à une étiquette "sortie" qui vous donne un message adéquat, et termine la commande.
Vous pouvez voir dans la suite comment le fichier s'y prend pour distinguer le nom du fichier (l'argument de List) du paramètre (la lettre correspondant à l'attribut qui guide la recherche).
En fait, si vous avez fait un peu de BASIC, vous constaterez que l'ensemble des commandes d'AmigaDOS constitue un langage de programmation, rudimentaire, certes, mais qui a le mérite d'exister.
C'est la fin (pour aujourd'hui)
Bon, je crois qu'il y en a assez pour aujourd'hui, mais ce n'est pas fini ; la prochaine fois nous verrons comment rendre une commande interactive, c'est-à-dire qu'à certains moments elle vous demandera votre avis sur la suite de son exécution.
Entretemps, si vous voulez approfondir ce genre de choses, les explications sur le passage d'arguments à un fichier script se trouvent en général dans la doc à la page qui décrit la commande Execute.
|
