|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Longtemps attendu, il ne déçoit pas ! WShell 2.0 est avant tout un Shell entièrement compatible avec le Shell de Commodore. C'est une condition obligatoire afin d'avoir des conditions de travail acceptables. Le manuel a changé de couleur par rapport à la version précédente et s'est quelque peu étoffé (une centaine de pages). Bien qu'en anglais, c'est un modèle de clarté. Signalons de plus qu'il a été rédigé entièrement avec l'Amiga (TurboText et AmigaTeX). Le Shell lui-même est intégralement écrit en assembleur (avec CAPE). ![]() Trois pages dans le manuel suffisent à expliquer l'installation de WShell. Un script est fourni sur la disquette afin d'automatiser cette installation (Install-WShell) mais pour ceux qui veulent connaître la procédure en détail, la voici :
Passons maintenant aux facilités offertes par WShell. Elles sont nombreuses. Le mécanisme de "piping" Il est très étonnant de voir que Commodore, après sept années, n'a toujours pas été capable de produire un système de "piping" de qualité (NDLR : on peut utiliser le "piping" avec le Shell d'AmigaOS 2.04). Heureusement, celui écrit par William Hawes est sans failles. Mais d'abord, qu'est-ce que le piping ? Il s'agit tout simplement d'un moyen pour faire communiquer deux commandes entre elles, typiquement pour rediriger la sortie d'une commande vers l'entrée d'une autre. Un exemple rapide :
Par défaut, le symbole pipe est la barre verticale ("|") mais il peut être aisément modifié, ainsi que tous les caractères spéciaux de WShell. Le résultat de la commande ci-dessus sera que la sortie de "list" sera redirigée en entrée de "more", vous permettant de visualiser plus facilement le répertoire. Les pipes peuvent être chaînés les uns aux autres :
Cette fois, la sortie de "list" sera triée avant d'être envoyée sur "more". Les possibilités du piping sont innombrables, surtout si vous couplez son usage avec la commande ExecI0, fournie également sur la disquette. Celle-ci vous permet de réaliser un nombre impressionnant de filtres, c'est-à-dire des commandes qui prennent une entrée, lui font subir des transformations (suppressions de lignes, de mots, remplacements, etc.) et envoient ce résultat sur la sortie standard. Je vous renvoie à la description de cette commande pour plus de détails. Notez aussi que WShell 2.0 vous autorise à positionner les redirections vers des fichiers (avec les symboles "<" et ">" n'importe où sur la ligne de commande). La commande DHOpts C'est la commande principale utilisée pour régler les options de la nouvelle console : le Display-Handler (Cf. le paragraphe suivant à son sujet). Dans sa fonction primaire, DHOpts se comporte comme "mount" et permet donc de monter des répertoires. Mais elle offre également beaucoup d'options pour donner la caractéristique de la nouvelle console. Ainsi, vous pouvez ouvrir celle-ci avec un gadget de fermeture (CLOSE), sur un écran public (SCREEN), avec une police de caractères spéciale (FONT, FONT-SIZE), avec l'ascenseur sur la gauche (LEFT), avec un menu (MENU), etc. La nouvelle console (Display-Handler) WShell réussit la performance d'apporter une nouvelle console plus perfectionnée que la console standard d'AmigaDOS (CON:) et de faire en sorte que celle-ci prenne la place de l'ancienne. Ainsi, toutes les nouvelles fenêtres ouvertes sur des consoles s'ouvriront avec la console de WShell. Pour réaliser ce tour de force, deux commandes suffisent :
La première instruction supprime la console standard et la deuxième installe celle de WShell à la place. Mais quels sont les avantages de cette nouvelle console ? Son point fort est sans aucun doute la présence d'une barre de défilement sur l'un des bords de la console. Ainsi, vous pouvez à loisir retrouver du texte qui ne figurerait plus sur l'écran et éventuellement le capturer pour le réutiliser. Cette barre de défilement se manipule naturellement à la souris mais peut également être entièrement pilotée avec le clavier grâce au nouveau FComp (Cf. le paragraphe qui lui est dédié pour plus de détails). Autre avantage non négligeable : la possibilité de mettre des menus dans chaque fenêtre (et éventuellement, un menu différent par fenêtre). Ceci peut se révéler très pratique selon que vous avez ouvert un Shell pour programmer, lancer des utilitaires, travailler sous Shell, etc. Du coup, ParM perd beaucoup de son intérêt. Les codes compris par la nouvelle console sont plus nombreux et plus fonctionnels que ceux de la console standard AmigaOS. L'appendice A du manuel donne la liste exhaustive de tous ces codes (deux pages entières !) vous permettant par exemple de reculer au mot précédent, d'échanger deux caractères, d'effacer jusqu'au début de la ligne, de rechercher dans l'historique, etc. De plus, la nouvelle commande "NewWSH" vous permet d'ouvrir un Shell en remplaçant celui qui existe initialement. Très pratique pour installer la nouvelle console à la place d'un Shell standard (lors du démarrage par exemple). Éditions de la ligne de commande Comme dans tous les Shell, l'édition dans la nouvelle console est grandement simplifiée. Tout d'abord, grâce au rappel avec les flèches des commandes précédentes, mais aussi grâce à tout un lot d'autres fonctions que ne possède pas AmigaDOS. D'abord, la recherche d'une commande commençant par une chaîne avec F6. Par exemple, si vous voulez reproduire une commande tapée précédemment commençant par "lha", il vous suffit de taper ces trois lettres, d'appuyer sur F6 et la première ligne de l'historique commençant de la sorte va se retrouver sur la ligne de commande. Inestimable ! Parmi les petits plus, je citerai également "^K" qui efface de la position courante du curseur jusqu'à la fin, et "^P" qui insère à l'endroit du curseur ce qui a été précédemment coupé. Grâce à FComp, il est possible de changer l'intégralité de ces commandes pour les adapter à l'environnement qui vous est le plus familier. Par exemple, un utilisateur régulier d'Emacs remplacerait très probablement la séquence "^P" par "^Y". Les possibilités sont infinies... Les commandes résidentes WShell 2.0 s'entend très bien avec AmigaDOS sur le plan des commandes résidentes. Bien que les deux Shell n'utilisent pas la même liste (l'un utilise la commande "resident", l'autre "resi"), WShell 2.0 est capable de parcourir les deux listes, et offre donc une compatibilité totale. Il commence bien entendu par rechercher dans sa propre liste de commandes résidentes et s'il ne trouve pas celle qui a été invoquée, il poursuit sa recherche dans la liste d'AmigaDOS. FComp C'est le "file completer". Il permet de s'abstenir d'avoir à taper de longs noms sous Shell. Par défaut, c'est la touche "Esc" qui permet la "complétion" mais il me semble plus judicieux de la redéfinir en "Tab". Il vous suffit donc de taper le début de votre commande, puis d'appuyer sur "Tab" et la ligne se complète automatiquement autant que possible. Par exemple :
Si après le "e", j'appuie sur "Tab", la ligne va automatiquement se compléter en :
Au cas où plusieurs fichiers avaient commencé par la lettre "e", FComp aurait commencé par afficher le premier et des appuis successifs sur "Tab" auraient fait défiler les autres. FComp étend son action aux noms de commandes (parcourus grâce à la variable d'environnement "Spath") et aux périphériques logiques et assignations logiques. De plus, son fichier de configuration permet encore plus d'acrobaties, par exemple le fait de dire "si la commande invoquée est "type", n'appliquer la complétion qu'aux fichiers se terminant par ".doc"". Mais la puissance de FComp ne se limite pas à cela : il est également possible dans le fichier s:Config-FComp de redéfinir intégralement le clavier (cette possibilité n'existait pas dans la version précédente de WShell). Ainsi, vous pouvez affecter aux touches de fonction certaines commandes régulièrement utilisées. Cette possibilité est déjà intéressante, mais la redéfinition du clavier laisse apparaître toute sa puissance quand elle est utilisée en conjonction avec WShell... Supposez que je veuille par exemple faire en sorte de remplacer la fonction exécutée par la touche "^P" (collage de la capture précédente du tampon mémoire) par "^Y". Tout d'abord, je cherche dans le fichier s:FComp-Keymap le code de "^Y". J'y apprends que le code du "Y" est 21 et que celui du "Ctrl" (le qualificateur) est 8. Ensuite, je regarde dans le manuel quelle est la chaîne à envoyer à la console pour provoquer l'insertion du tampon mémoire. En l'occurrence, il s'agit de "ESC[48]". Il ne me reste plus qu'à ajouter dans mon fichier s:Config-FComp la ligne suivante :
Et le tour est joué. Cette méthode peut naturellement s'étendre à toutes les touches et combinaisons possibles. Vous pouvez ainsi reprogrammer votre clavier pour manipuler le défilement de la fenêtre avec le pavé numérique (8 et 2 pour faire défiler d'une ligne, 3 et 9 pour se déplacer de page en page et 1 et 7 pour aller en haut ou en bas). Les lignes du fichier "Config-FComp" correspondantes sont les suivantes :
Il s'agit là d'une fonction directement héritée d'Unix et que William Hawes a décidé d'ajouter dans son Shell. Le symbole par défaut est l'accent grave ("`") et il suffit d'encadrer une commande par deux de ces symboles pour obtenir la substitution de cette chaîne par le résultat de l'exécution de la commande. Si par exemple je désire éditer un script Shell mais que j'ai oublié le répertoire dans lequel il se trouve, il me suffit de lancer la commande (en supposant naturellement que ce script se trouve dans le "path") :
Le Shell va dans un premier temps lancer la commande `which script` ce qui va avoir pour résultat d'afficher l'endroit précis où se trouve le fichier "script", et c'est ce chemin qui va être passé en argument à "ed" . Simple et terriblement efficace, surtout que cette fonction peut s'étendre à la gestion de l'invite de commande et de la barre de menus. Cf. la section correspondante. ARexx toujours présent Ne perdons pas de vue que WShell et ARexx sont en symbiose totale (mais vous pouvez utiliser l'un sans l'autre, naturellement). C'est très utile pour lancer des commandes ARexx d'une ligne directement sur la ligne de commande ou sans avoir à les faire précéder de "rx", qui est l'interprète ARexx. Hawes a simplifié le mécanisme par lequel vous invoquez une commande ARexx à partir de la ligne de commande. Tout ce qui est requis désormais est de commencer la ligne par un guillemet ("). Ainsi, il n'y a plus d'ambiguïté si la ligne que vous voulez taper contient à son tour des guillemets. Par exemple, si je désire connaître la liste de tous les ports présents sur mon système, je tape :
Ainsi, WShell peut se passer de langage de commande : il suffit d'écrire vos scripts en ARexx et vous pourrez les invoquer aussi simplement qu'un script AmigaDOS dont vous auriez levé le drapeau "s" (commande "chmod fichier +s"). Les variables d'environnement Autre nouveauté avec WShell : la gestion du "$" dans les variables d'environnement. Celles-ci résident dans le répertoire "env:" et vous pouvez connaître leur valeur de deux façons. Soit en utilisant le getenv d'AmigaDOS, soit en utilisant le "$" :
La variable d'environnement "$titlebar" est toujours présente et vous permet de mettre des titres particuliers à votre Shell. Par exemple, la mienne affiche le répertoire courant et la mémoire disponible :
La commande prompt C'est elle qui vous permet de personnaliser l'invite du CLI, de la même façon que la barre de titre, comme je l'ai expliqué au paragraphe précédent. Vous disposez là aussi de toute une batterie de symboles pour représenter l'heure du jour, la mémoire disponible, le résultat de la dernière commande, le temps écoulé depuis la dernière invite de commande, etc. Mon invite de commande est composée de ces deux dernières indications :
Malgré la vingtaine de possibilités offertes par les symboles prédéfinis de Hawes, celui-ci a estimé que les utilisateurs de son Shell pourraient être plus exigeants. Il autorise donc à mettre dans l'invite de commande un programme (une commande ARexx ou n'importe quel exécutable) dont le résultat sera inséré et servira d'invite de commande (un peu comme la fonction "backquote")... Le gestionnaire de "paths" Autre bijou de la distribution de WShell : PathMan. Celui-ci vous permet d'utiliser des assignations s'étendant sur plusieurs répertoires. Un usage immédiat de ce genre de facilité est par exemple d'assigner "fonts:" à deux répertoires, voire plus. Son installation est des plus simples (Cf. le chapitre sur l'installation) est la syntaxe est la suivante :
Désormais, toute consultation du répertoire logique "fonts:" parcourra en réalité les deux répertoires donnés en arguments. Autre application possible : si vous avez décidé d'avoir d'un côté un répertoire "c:" contenant la distribution originale de votre Workbench et un répertoire "bin:" rassemblant tous les utilitaires qu'il vous arrive d'ajouter (cette organisation est fortement recommandée), vous avez probablement envie de voir ces deux répertoires jouer le même rôle. Vous pouvez le faire avec la commande :
Ainsi, inutile d'ajouter "dh0:bin" dans votre chemin (path) car il fait désormais partie intégrante de "c:" qui est le répertoire parcouru par défaut. Et toujours... Tout ce qui n'est pas décrit dans cet article et qui se trouvait dans la version précédente de WShell figure également dans WShell 2.0 (avec notamment ExecIO) ainsi qu'un petit extra dont je vous avais parlé dans un précédent article : Snap. En conclusion Après trois mois d'utilisation de WShell 2.0, je ne lui reproche que trois petites choses :
Adresse de l'auteur : William Hawes Wishful Thinking Development Corp. PO Box 308 Maynard, MA 01754, États-Unis (508) 568 8695
|