 |
Mercredi 24 avril 2024 - 11:32 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Cette fois, nous allons examiner un produit commercial, il s'agit de la version 1.2 de WShell de William Hawes. C'est la dernière sortie, elle comporte des différences sensibles par rapport aux versions précédentes. Ce programme avec sa documentation vous coûtera 40 $ plus les frais d'envoi si vous le commandez directement chez l'auteur ; il accepte le paiement par carte de crédit.
Voici ses coordonnées :
William S. Hawes
P.O. Box 308
Maynard, MA 01754
États-Unis.
Mais vous pouvez tout aussi bien le commander chez un distributeur comme Briwall ou Go-Amigo, qui le vendent aux alentours de 32 $.
WShell, comme ASH, reste le plus proche possible de l'AmigaShell, tout en y apportant des améliorations dont certaines sont uniques en leur genre (pour n'en citer qu'une : la reconnaissance au même titre qu'une ligne de commande, d'une série d'instructions du langage ARexx) et dont le nombre et la puissance sont impressionnants.
Documentation et installation
WShell vous arrive sous la forme d'une disquette et d'un manuel imprimé de 60 pages. Sur la disquette, il y a encore un fichier "Readme" et un fichier "Update.doc" (13 pages en tout en impression condensée) dont la lecture est indispensable car ils contiennent presque autant d'information que la doc imprimée. Heureusement, ou malheureusement, il y a des redondances entres le contenu de ces fichiers et celui du manuel, mais il y a aussi des choses à ne pas ignorer. Pour en terminer avec la doc, il y a quelques erreurs dans l'index alphabétique.
Parlant de la disquette, on y trouve encore le programme de base WShell, deux scripts d'installation, et une série de répertoires portant les noms C, ConMan, Extras, Filters, PathMan, rexx, libs, s et sources. Cet ensemble va se révéler être une mine de choses intéressantes.
Le fichier "Readme" contient, par ailleurs, une liste de tous les fichiers présents sur la disquette, avec un mot sur leur contenu.
L'installation ne demandera pas une longue description, elle est bien documentée, facilitée par des fichiers de commandes ad hoc ; nous n'aurons donc pas à nous y attarder. Les séquences de démarrage sont fournies.
Il serait dommage de ne pas utiliser les commandes ARP. La dernière version de WShell ne comporte plus la fourniture des commandes ARP, il faut se les procurer séparément.
Grâce à l'économie de place obtenue en adoptant les commandes ARP, et en éliminant de la disquette tout ce qui est propre à l'AmigaShell (commandes, handlers) ainsi que les répertoires "Utilities" et "Fonts" (il y a toujours la Topaz en ROM), on peut caser sur la disquette système tout ce qui est fourni sur la disquette WShell, sauf bien sûr les fichiers de doc. Il reste alors une petite centaine de blocs.
Franchement, je pense qu'à partir du moment où on va utiliser WShell et ARexx, un disque dur est bienvenu ; néanmoins, on peut travailler avec un seul lecteur de disquette. Si on manque de place, on peut charger séparément en mémoire des bibliothèques encombrantes à partir d'une autre disquette par la commande "Loadlib" fournie.
Incidemment, W. Hawes développe sur un Amiga 1000 avec 512 ko, deux lecteurs de disquette 3,5" et sans disque dur. Il estime que l'extension de mémoire et le disque dur donnent des habitudes laxistes ; François Rouaix qui a regardé en détail la manière dont sont écrites les bibliothèques de WShell déclare avoir rarement vu des choses aussi astucieusement et aussi proprement écrites.
Il ne reste qu'à démarrer sur la disquette pour voir si tout marche bien. Le résultat cause un petit choc, on a l'impression d'être entré dans l'appartement de quelqu'un d'autre. La barre supérieure de la fenêtre porte une ligne de ce genre :
| New WShell 2 at 0x002149A0 [2947888 free] >>> Workbench1.3 |
Et l'invite de commande est :
| R(0); 7:25 PM > |
Rassurez-vous, rien ne sera plus facile que de retapisser l'appartement avec le dessin à fleurs dont vous avez l'habitude. Nous reviendrons bien sûr en détail sur cette présentation.
Compatibilité avec l'AmigaShell
WShell remplace purement et simplement l'AmigaShell. On peut garder les commandes Commodore. Par contre, nous avons de bonnes raisons d'y substituer les commandes ARP, et nous savons qu'elles sont conçues pour ne pas dépayser l'utilisateur habitué à l'AmigaShell. L'auteur s'est efforcé de réaliser la plus grande compatibilité ; il met simplement en garde contre le fait que certains programmes du type "Make" utilisé avec des compilateurs peuvent poser un problème s'ils sont invoqués directement, auquel cas ils marchent généralement avec la syntaxe "Run Make".
Les commandes
Les commandes internes
Il y a 22 commandes internes dans WShell. Tout d'abord, les commandes classiques : Cd, Echo, If, Else, Endif, Endcli, Failat, Lab, Prompt, Quit, Skip, Stack, mais on trouve aussi, qui n'étaient disponibles ni dans AmigaShell, ni dans ARP : Goto, Pause, Mounted, Popcd, Pushcd, Swapcd et Rexx.
WShell maintient une pile dans lequel il stocke des noms de répertoires :
Pushcd suivi du nom d'un répertoire introduit le nom de ce répertoire (chemin complet) dans le bas de la pile ; en l'absence d'argument, c'est le nom du répertoire courant qui est stocké.
Popcd retire de la pile le nom le plus bas, c'est-à-dire le dernier entré, et ce répertoire devient le répertoire courant.
Swapcd échange le répertoire courant avec celui qui est en haut de la pile. Si vous avez l'habitude d'une calculatrice à notation polonaise inversée, vous n'aurez aucun problème à utiliser ce dispositif.
Goto label remplace Skip et Skip Back. C'est un peu plus commode mais il n'y a pas encore de quoi pavoiser, car on ne peut pas faire de boucles de type "FOR...NEXT" ou "WHILE...WEND".
Par contre, on peut invoquer directement un programme ARexx qui pourra comporter des boucles du style "DO...END", ou tout simplement écrire dans une fenêtre WShell, sous forme de lignes de commandes, des macros ARexx comportant des boucles.
La commande Rexx de WShell se différencie par plusieurs aspects de la commande "rx" d'ARexx, l'un d'eux étant que la commande Rexx ne permet pas l'exécution d'un programme ou d'une macro ARexx récursif ; on aura recours pour cela à la commande "rx" (la documentation indique d'utiliser dans ce cas la commande interne "rexx" en minuscules, mais je n'ai pu mettre en évidence aucune différence par rapport à la commande en majuscules ; par contre la commande "rx" permet la récursivité). Cette disposition est destinée à éviter des récursions accidentelles.
La commande Mounted vérifie si un "device" a été activé ; dans la négative elle retourne un code 5 (warn).
Il y a encore une commande interactive Pause, sans équivalent dans les commandes AmigaDOS ; elle arrête l'exécution du script, affiche le message qu'on lui a donné comme argument, et attend la réponse sous forme d'une commande AmigaDOS ou d'un équivalent. Exemple :
Les autres commandes
Outre les commandes internes, il est fourni dans le répertoire "c:" de la disquette les commandes suivantes : Conman, History, Loadlib, Newwsh, Patchwb, Runwsh, Setcman, Setexecute, Swaphistory.
Il y a aussi un répertoire "Filters" dans lequel on trouve, entre autres, une commande, ExecIO, qui fonctionne comme une copie ligne par ligne entre les flux d'entrée et de sortie du processus WShell en cours ; si on l'invoque depuis une macro ARexx, elle permet de transférer de l'information directement dans une variable de ce programme. Un exemple d'application serait de fragmenter un long fichier, sans passer par un éditeur, ou sans être gêné par la taille limite du fichier qu'un éditeur peut charger. ExecIO comporte de nombreuses options ; signalons la possibilité de loger les lignes extraites du fichier dans des variables, de n'extraire que les lignes qui contiennent ou au contraire qui ne contiennent pas une chaîne donnée, de contenir le traitement d'une ligne entre deux colonnes données. Cette commande est extrêmement puissante, il y a sur la disquette un programme IOTest qui donne des exemples d'utilisation.
Enfin, il y a dans WShell une commande invisible ! C'est le CD implicite. Il suffit de taper le nom d'un répertoire pour qu'il devienne le répertoire courant. Ceci peut être gênant lorsque le nom d'un répertoire est le même que celui d'une commande que l'on veut exécuter. Exemple : si, étant dans le répertoire racine d'une disquette Fish où il y a, entre autres, un répertoire "LS", je fais "LS" pour voir le contenu du répertoire racine, ceci sera interprété par WShell comme un "CD LS" implicite et le répertoire "LS" deviendra le répertoire courant, ce qui n'était pas l'effet recherché. Pour cela, le CD implicite est désactivé dès qu'il y a une redirection dans la commande ; il suffira donc de faire "LS >*" et tout rentrera dans l'ordre. Ceci est un exemple de la rançon à payer pour un degré donné de sophistication. Certains jugeront peut-être que dans le cas présent, la sophistication est inutilement élevée et je ne leur donnerai pas tort.
Il y aurait encore bien des choses à signaler dans ce chapitre, mais ce n'est pas un commentaire exhaustif de toute la documentation !
Différences de syntaxe, caractères génériques, alias
Peu de choses à dire ici, comme on utilise les commandes ARP, voir l'article précédent.
Les choses intéressantes sont au niveau des commandes résidentes et des alias, et de Newwsh.
La commande Resi remplit la même fonction que "Resident", mais bien sûr avec de nombreuses possibilités supplémentaires. Comme dans ASH (le gestionnaire de ARP), WShell teste l'intégrité du code des commandes résidentes à chaque invocation et donne un message d'erreur en cas d'altération.
Tout d'abord, on peut mettre jusqu'à dix commandes résidentes au moyen d'une seule commande "Resi" ; l'option "Auto" a pour résultat le chargement de la commande en mémoire à sa première invocation, comme dans ASH ; la commande "Resi" sans argument donne la liste des commandes résidentes, par ordre décroissant du nombre d'invocations de la commande depuis le début de la session ; la syntaxe "Resi -List xyz..." limite la liste aux commandes dont le nom commence par les caractères "xyz...".
Alias est classique dans son fonctionnement, à une intéressante différence près, qui est la possibilité de définir des abréviations multiples pour une commande en jouant sur les majuscules et les minuscules. Les règles sont aussi simples mais aussi difficiles à appliquer que celles du jeu de go ; voici simplement un exemple :
| Alias MAkeDir makedir |
...permet d'utiliser pour "Makedir" les abréviations : "ma", "mak", "maked", "makedi", mais pas "m" ni "make".
| Alias MKdir makedir |
...permet d'utiliser les abréviations : "mk", "mkd", "mkdi" et "mkdir".
Devinez les trois règles. Ceci est néanmoins très pratique quand on doit travailler toute la journée sur un système qui a des abréviations données et le soir sur son Amiga. Pour éviter toute confusion, lorsqu'un alias est tapé, la commande complète qu'il représente est affichée.
L'édition des lignes de commande
Ce sont d'une manière générale celles de ConMan ; elles sont connues, je rappellerai simplement qu'il y a 33 fonctions d'édition des lignes de commande et de recherche dans l'historique, définies par des pressions de touche.
Exemple : en frappant les premières lettres d'une ligne de commande précédemment exécutée, puis F6 (ou F5), cette commande est recherchée en amont (ou en aval) dans l'historique et affichée.
La recherche de fichiers par leurs initiales (FComp)
Il y a dans la version 1.2 de WShell une nouveauté intéressante qui est la fonction "Compléter le nom d'un fichier" que l'on trouve dans les Shells Unix. Il est fourni pour cela, dans un répertoire "FComp", une commande "FComp" à mettre dans "C:" et un fichier de configuration "Config-FComp" à mettre dans "S:". L'idée de base est simple : après avoir lancé la commande "FComp", le mode "Compléter" est activé ; il suffit alors de frapper les premières lettres d'un fichier, puis "Esc", pour que le nom complet du fichier s'affiche s'il est dans le répertoire courant, ou dans l'un des chemins courants. On peut s'en servir comme ceci sans autre considération, mais bien entendu l'auteur a muni cet utilitaire de possibilités nombreuses et puissantes.
Tout d'abord, la commande "FComp" accepte elle-même une série d'arguments qui vont lui donner des caractéristiques modifiables à tout instant, mais on peut définir un certain nombre d'autres caractéristiques dans le fichier de configuration. Celui-ci peut être le fichier par défaut "s:Config-FComp", mais aussi n'importe quel fichier de configuration défini par l'utilisateur, et appelé par la syntaxe :
| FComp FROM fichierdeconfig |
Voyons d'abord ce qu'il y a dans ce fichier de configuration :
1. Des définitions de touches
Lorsqu'on a tapé les premières lettres du fichier à trouver, puis "Esc", on peut agir sur le mode de présentation du résultat en frappant une touche pour laquelle on a donné une définition dans ce fichier de configuration. On trouve par exemple dans le fichier de configuration fourni :
| KEY 62 FMT "%f%0%l" AUTO |
Ceci fera exécuter la commande complétée, en tapant "8" sur le bloc numérique du clavier (à condition qu'il n'y ait qu'une commande qui satisfasse au critère de recherche).
Les formats d'affichage sont définis par des paramètres :
- %f : première partie de la ligne de commande.
- %l : dernière partie de la ligne de commande.
- %0 à %9 : les noms des fichiers à compléter, etc.
- %e : extension.
- %h : "tête" (head), chemin sans le nom du fichier.
- %r : nom complet avec le chemin.
- %t : "queue" (tail), nom du fichier sans le chemin.
| KEY 29 FmT "; Choices: %0 %1 %2 %3 %4 %5 %6 %7 %8 %9" |
Ceci fera afficher les dix premières commandes ou fichiers qui satisfont au critère de recherche.
2. Des définitions de commandes
Sur ces lignes, on définit pour l'argument d'une commande déterminée, les paramètres de définition des chemins de recherche, les caractères concordants et les caractères génériques (pattern), le format de la ligne de commande (position des arguments, etc.), l'exécution d'office (ajout automatique d'un "Retour"). Il y a deux usages possibles de ceci. Le plus évident est l'exécution d'une commande, en donnant les initiales de l'argument. Par exemple, pour la commande "Execute", on spécifierait pour l'option "Path" le chemin "S:", ce qui limiterait la recherche au répertoire "S:" et au répertoire courant.
Le cas plus subtil d'utilisation de cette possibilité est celui d'un programme ou d'un fichier de commande, qui demande à un instant donné une réponse à l'utilisateur. Ce dernier ne sait pas nécessairement quelle est la commande à laquelle il doit passer un argument ; si cette commande a été définie dans le fichier de configuration de FComp, FComp l'a reconnue, sait qu'elle attend des paramètres, effectuera la recherche de fichier et donnera à la ligne de commande le format adéquat.
Nous pouvons à présent revenir sur les paramètres de la commande FComp elle-même.
Path, Nopath ne demandent pas de commentaire, sinon que par défaut FComp ne fera pas de recherche dans "C:" à cause du grand nombre de commandes qui s'y trouvent habituellement ; on pourra forcer l'extension de la recherche à "C:" en utilisant l'option "Path".
Si FComp a été lancé avec les options Sort et Group, et qu'on a frappé une clé qui affiche un choix (voir plus haut), les noms des fichiers trouvés seront classés en "devices", répertoires et fichiers, et triés par ordre alphabétique dans chaque catégorie. Il y a aussi trois options destinées à la gestion de la mémoire tampon de FComp, Meminit, Memcheck et Memmax, leurs noms sont assez explicites.
FComp est un outil très puissant mais il faut un peu d'habitude pour travailler avec ; en particulier, tant qu'il n'a pas trouvé ce qu'il voulait, l'écran clignote avec un "bip" à toute pression d'une touche du pavé numérique, ce qui est normal vu leur redéfinition par le fichier Config-FComp.
Les améliorations de l'environnement de travail
Les fenêtres WShell
Pour ouvrir une fenêtre WShell et en définir les caractéristiques, il y a sept dispositifs qui collaborent :
- Les bibliothèques : WShell.library et ConHand.library.
- Le gestionnaire de fenêtres CON:, avec la "rallonge" ConHandler.
- Le programme ConMan.
- Le fichier de configuration globale S:Config-WShell.
- Le fichier de configuration locale S/WShell-Startup.
- Un ensemble de variables d'environnement.
- La commande Newwsh.
Rappelons que ConMan permet, par ses paramètres, de créer des fenêtres activées ou non à l'ouverture, en avant-plan ou en arrière-plan, avec ou sans gadget de fermeture, avec ou sans bordure, etc.
La commande Newwsh ouvre une fenêtre WShell, avec des caractéristiques reçues du fichier Config-WShell, mais aussi d'un fichier qui est par défaut Startup-WShell ; la commande Runwsh lance un programme en arrière-plan ; on obtient le même effet en tapant le nom de la commande suivi de "&". Les caractéristiques "physiques" de la fenêtre sont déterminées par le contenu des variables d'environnement mentionnées ci-dessus.
Le fichier Config-WShell
Le fichier Config-WShell permet d'activer certaines options lors de l'ouverture de la première fenêtre WShell. Ces options sont globales en ce sens qu'elles resteront valables par la suite pour toutes les fenêtres WShell, quelle que soit leur filiation.
Il y a quatre éléments de configuration, constituant chacun une ligne du fichier : Options, Special, Alias et Resi.
Options :
- Cachelim, taille maxi du programme ou de la commande qui reste en mémoire tampon entre deux lignes de commande.
- Autopush fait un PUSCD automatique à chaque changement de répertoire.
- Checkicon vérifie dans le fichier d'icône d'un programme si la taille de la pile est suffisante pour ce programme, et au besoin l'ajuste.
- Nobatch supprime l'affichage des commandes d'un fichier script lors de l'exécution.
- Changed limite le réaffichage de la commande aux cas où une abréviation a été utilisée. Voir plus loin la variable "Echo".
- Oneback ne prend en compte le caractère "&" que s'il est le dernier de la ligne.
- Spegarg permet d'utiliser les caractères spéciaux "<", ">", "|", "&" et ";" comme arguments d'une commande s'ils sont précédés du caractère d'échappement.
Alias : permet de définir des alias globaux.
Resi : permet la mise résidente en mémoire des commandes ; ce qui peut se faire aussi bien ici que dans la séquence de démarrage.
Le fichier Startup-WShell
Il a un rôle identique à celui du fichier Shell-Startup de l'AmigaShell. On y trouvera normalement des alias locaux et la définition de l'invite. On peut aussi y mettre un petit programme nommé CliColors qu'on trouve au fond du répertoire "Extras", et qui change les couleurs de la barre de titre et du texte qui s'y trouve en fonction du numéro de la fenêtre WShell (huit combinaisons). Ceci peut se révéler très pratique lorsqu'on travaille dans plusieurs fenêtres à la fois.
Les variables d'environnement
Là, une fois de plus, l'auteur a laissé libre cours à son imagination. Les variables d'environnement intéressant les fenêtres WShell sont Echo, Shellwindow, Titlebar et Prompt.
Echo peut prendre les valeurs "ON" et "OFF". Avec "ON", après chaque ligne de commande, on a sur la ligne suivante une flèche suivie de la répétition de la commande, complétée lors de l'utilisation d'alias ou de FComp ; lors de l'exécution d'un fichier de commandes, ceci joue le rôle d'une fonction "Trace" lors de la mise au point d'un programme. Dans les alias du fichier Config-WShell, il y a deux abréviations "Tron" et "Troff" équivalentes à "Setenv Env:Echo ON" et "Setenv Env:Echo OFF".
Shellwindow est une chaîne qui contient la définition de la fenêtre et la désignation du gestionnaire ; exemple :
| CON:0/0/640/200/MaFenêtre/c/23 |
"c" lui confère un gadget de fermeture.
"23" met le titre en noir et la bordure en rouge.
Titlebar et Prompt sont les chaînes qui définissent le contenu et le format du texte figurant dans la barre de titre et dans l'invite. Comme il n'y a pas moins de 18 paramètres disponibles, je ne vais pas les citer tous, mais en particulier :
- %C ou %c donnent respectivement le chemin complet ou abrégé (c'est-à-dire à partir du répertoire courant).
- %MC ou %mc donnent la mémoire Chip disponible.
- %MF ou %mf donnent la mémoire Fast disponible en octets ou en koctets respectivement.
- %R donne le code de retour de la dernière commande.
Tout ce dispositif permet de personnaliser les fenêtres à plusieurs niveaux : aspect, informations données en permanence, type d'abréviations utilisées, définition de chemins de recherche particuliers. On peut donc travailler simultanément dans des environnements très divers.
Les pipes
Voir à ce sujet ce qui a été dit dans l'article sur ASH, c'est la même chose. WShell fournit d'intéressants filtres à utiliser dans les pipes, comme "ExecIO" déjà examiné, ou "Tee" qui permet de rediriger la sortie d'une commande vers deux destinations simultanément, par exemple l'affichage et un fichier.
L'utilitaire PathMan
Ceci est un petit cadeau qui pourra se révéler bien utile. PathMan se présente sous la forme d'un gestionnaire PathHandler à mettre en "L:", une entrée "Path:" à faire dans la liste de montage (un script pour le faire à votre place est fourni), et un utilitaire de mise au point PathWack à mettre dans "C:".
L'explication se fera le mieux par un exemple : après avoir fait "Mount Path:" la ligne...
|
Assign PP: Path: Devs:Printers, DF0:Devs/Printers, DH2:Drivers, DH3: |
...définit comme chemin de recherche d'un fichier, par exemple un pilote d'imprimante, les répertoires "Devs:Printers", "DF0:Devs/Printers", "DH2:Drivers" et "DH3:", ce qui permet par exemple d'éviter de surcharger une disquette système en élargissant la possibilité de chemins de recherche à d'autres unités physiques ou logiques.
Comme on pouvait s'y attendre, il y a des raffinements, comme le fait de pouvoir définir des alias pour ces définitions de chemins multiples, ou de leur fournir des attributs de protection, afin de permettre par exemple la lecture mais ni la modification, ni la destruction des fichiers se trouvant sur ces chemins.
L'utilitaire PathWack sert à mettre au point ces mécanismes, en affichant dans une autre fenêtre WShell les étapes de la recherche que fait PathMan. L'auteur prévient aimablement du fait que PathMan en est encore au stade expérimental, mais devrait néanmoins marcher correctement. Le pépin qui m'est arrivé est que PathWack a refusé de s'arrêter par "Ctrl-C" comme le suggère la doc, avec comme résultat une fenêtre non refermable.
Snap
Enfin, bien que ceci n'ait au fond rien à voir avec un Shell, en ouvrant à fond le tiroir "Extras", on trouve un truc qui s'appelle "Snap". Cet utilitaire est destiné à saisir une partie de l'écran, soit en mode texte, soit en mode graphique, à stocker cette partie dans le répertoire "Clips:", et à le restituer dans la même fenêtre ou dans une autre.
Je me suis contenté de vérifier que le mode texte transfère bien la portion de texte encadrée dans une fenêtre WShell, dans une fenêtre de l'éditeur AZ, et dans une fenêtre ProWrite. Il faudrait l'essayer à fond, car Snap a le mérite de fonctionner, et aussi de reconnaître quelques autres polices que le Topaz 8. Ces deux points Snap différencient de ses collègues ClipIt et de SnipIt qui ne m'ont pas donné de bons résultats. Je dois toutefois signaler que si Snap fonctionnait sous WShell et sous AmigaShell, je ne suis pas arrivé à le faire marcher correctement dans un environnement AShell. Attendez-vous toutefois à un apprentissage peu évident et à une bonne dose de plantages. Une fois la procédure maîtrisée, c'est très agréable.
Voilà pour l'environnement de travail !
Les scripts
WShell reconnaît l'attribut "S" de l'AmigaShell, et permet donc l'écriture de fichiers de commandes de manière classique, et l'exécution de fichiers de commandes existants.
La grosse nouveauté est la possibilité de travailler en coopération avec ARexx. Si vous installez, lorsqu'il sera disponible, le Workbench 1.4, il devrait en principe inclure ARexx. Sinon, ajoutez ARexx à WShell, ça vaut la peine. Il faut tout de même savoir que les bibliothèques et l'interpréteur résident d'ARexx occupent environ 40 ko de mémoire.
Ceci dit, les programmes ARexx s'invoquent comme on l'a vu par les commandes Rexx et rx, ou même en invoquant simplement leur nom s'ils sont dans un des chemins de recherche courants. Il est très facile et rapide, grâce à n'importe quel éditeur, d'écrire un programme ARexx de quelques lignes pour réaliser une opération que l'on effectue souvent ; comme il s'agit d'un langage de programmation, il comporte toutes les possibilités de boucles et de tests logiques souhaitables ; de plus, on peut de l'intérieur d'un programme ARexx invoquer d'autres programmes ARexx et des commandes AmigaDOS ou WShell.
Exemple :
Le fait d'avoir sous la main en permanence un langage de programmation interprété, interactif, peu encombrant et relativement rapide, est appréciable.
Les interfaces avec les programmes
Nous venons de voir qu'un programme ARexx possède une interface avec WShell, puisqu'il peut invoquer directement des commandes. Il pourra échanger de l'information avec WShell car chaque processus WShell ouvre d'office dans les programmes ARexx qu'il lance un "message port" nommé "WSH_n", où "n" est le numéro de la tache WShell en cours.
Conclusion
Simplicité quand je le souhaite, puissance si je veux, WShell est à l'image de l'Amiga. Notre machine a une foule de possibilités, rares sont ceux qui les utilisent toutes à fond. On peut acheter un Amiga, utiliser de nombreux programmes et même programmer sans utiliser le CLI ou le Shell ; il y a des éditeurs et des compilateurs fonctionnant entièrement sous Workbench, et l'évolution prévisible de ce dernier, est de permettre de faire de plus en plus de choses pour lesquelles il faut à l'heure actuelle utiliser les commandes du système d'exploitation.
Pour faire des choses plus complexes, il faut avoir recours à ces commandes, et c'est là qu'un bon Shell s'apprécie. Je ne pense pas, pour ma part, qu'AmigaDOS 1.4, pour ce qu'on peut en lire jusqu'à présent, rendra un outil comme WShell inutile.
WShell peut s'utiliser tel quel, je dirais tout naturellement, pour quelqu'un qui a déjà l'habitude de l'AmigaShell. La dernière des choses à faire, sauf pour les spécialistes, est de lire à fond toute la doc ; rien que le contenu du présent article, qui est loin d'être une analyse complète, peut donner l'idée que WShell est une "usine à gaz", et qu'il y a beaucoup de choses à se mettre en tête.
Le mieux est sans doute d'y aller progressivement, et, chaque fois qu'on a un problème particulier, d'avoir le réflexe "avec WShell, ça doit être possible". Vous ne risquez pas d'être déçu. De plus, la chose sera généralement possible de deux ou trois manières différentes, à vous de choisir !
Enfin, il ne faudrait pas que le fait que WShell comporte beaucoup d'aspects "cosmétiques", vous amène à passer à côté de possibilités puissantes comme ce qui existe au niveau des alias, des pipes et des filtres.
Ceci dit, WShell prend toute sa puissance en association avec ARexx ; ce mélange détonnant est sans doute ce qu'il y a de plus puissant dans le genre ; nous verrons ce qu'on peut en penser lorsque nous aurons examiné les Shells de type Unix dans les prochains articles.
|
