 |
Samedi 20 avril 2024 - 14:43 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Après quelques mois de repos, nous sommes prêts à reprendre notre étude des Shells. Comme prévu, nous examinerons dans cet article CSH. Malgré l'apparition d'AmigaOS 2.0, les Shells du domaine public conservent tout leur intérêt, l'AmigaShell du 2.0 et ses commandes n'ayant subi que des améliorations nominales.
J'attire une nouvelle fois l'attention sur le fait que, contrairement à une opinion largement répandue, le 2.0 n'incorpore pas les "vraies" commandes ARP. Beaucoup de commandes du 2.0 sont internes, toutes ont été réécrites et l'ensemble est nettement moins encombrant, mais elles ne possèdent en aucune façon la souplesse ni la puissance des commandes ARP, ni d'ailleurs celles des commandes internes des Shells que nous étudions, tout en gardant dans certains cas précis des caractéristiques uniques.
CSH
CSH est en fait le bon vieux Shell de Matt Dillon, amélioré par Carlo Borreo et Cesare Dieni, il s'agit de la version 4.01 qui se trouve sur Fish 331. C'est la dernière version disponible au moment de la rédaction de cet article. Pour ceux qui disposeraient d'une version précédente, plusieurs bogues ont été corrigés, entre autres, la redirection de la commande RPN et le dysfonctionnement de la commande rxsend (bye).
Matt Dillon a sorti son Shell il y a très longtemps, lorsqu'il n'y avait sur l'Amiga que le CLI, interface utilisateur rudimentaire s'il en fut. Le temps passe vite, lorsque j'ai touché mon Amiga 2000A en juillet 1987, il était livré avec le Workbench 1.2 et le CLI. L'AmigaShell de Commodore n'est apparu qu'avec la sortie de du Workbench 1.3 en 1988. Le Shell de Matt Dillon fut donc très apprécié à sa sortie.
Sur les systèmes Unix, on trouve en général les Shells suivants : le Shell Bourne, le plus élémentaire, le C Shell plus puissant, et le Korn Shell, un cocktail des deux premiers. CSH est un Shell qui tend à se rapprocher du C Shell d'Unix.
Documentation et installation
On ne peut pas dire que la documentation soit maigre, elle fait huit pages de 80 lignes. Néanmoins, elle est d'une concision extrême et il s'agit davantage d'un document de référence que d'un outil didactique. Le vocabulaire est typique d'Unix ; "Execute" s'appelle "Source" et un script est un "Source File". L'effort de conversion à faire n'est pas très grand ; toutefois, il ne faudrait pas croire que CSH ne s'adresse qu'à des adeptes d'Unix, c'est comme on le verra un Shell très intéressant à plus d'un titre.
Contrairement à ce qui se passait pour tous les Shells précédents (Shell ASH et WShell), il n'y a pas d'installation, il suffit de recopier dans le répertoire Libs: la bibliothèque ARP 1.3, et dans le répertoire C: le fichier Shell, qui pèse gentiment 46 524 octets.
Contrairement aussi à ce qui se passait pour les autres Shells, la commande Shell de CSH n'ouvre pas une fenêtre. On la tape dans une fenêtre déjà ouverte (sous n'importe quel autre Shell d'ailleurs, ou même sous CLI), l'invite change et une partie de la gestion de la console est alors prise en charge par CSH. Pour ouvrir une nouvelle fenêtre avec CSH activé, il faut inclure une commande "Shell" dans le fichier S:Shell-Startup.
Cette conception est due aux idées de Matt Dillon qui considérait que ce n'est pas le boulot d'un Shell que de gérer la console. C'est pourquoi il n'y a pas, associé à CSH, un gestionnaire de console qui jouerait le rôle de CON:, NEWCON:, ASH et CNC: dans les cas respectifs de CLI, AmigaShell, AShell et ConMan/WShell. L'utilisation de CSH demande donc la présence d'un gestionnaire de console actif.
En bref, pour ceux qui voudraient voir la chose exprimée plus simplement, prenez votre système 1.3 standard, avec la bibliothèque ARP 1.3 dans Libs: et Shell dans C:, et vous pourrez travailler sous CSH dans chaque fenêtre que vous aurez ouverte, en tapant simplement "Shell".
Compatibilité avec l'AmigaShell
Dans les articles précédents, nous avions traité dans ce chapitre de la possibilité d'utiliser sous le Shell étudié les commandes Commodore.
Dans le cas présent, il n'y a pas moins de 75 commandes internes. Elles ne remplacent pas toutes les commandes Commodore. Il y a 32 commandes Commodore qui n'ont pas d'équivalent dans CSH, comme BindDrivers, ce qui est logique. Vous aurez donc à votre disposition, dans une fenêtre AmigaShell avec CSH activé, plus de 100 commandes, et encore un peu plus si d'aventure vous aviez déjà installé les commandes ARP.
Cette débauche de commandes a ses avantages et ses inconvénients. Ces derniers ont principalement trait aux différences de syntaxe, que nous examinerons au chapitre suivant. Le bon côté des choses est que l'ensemble des commandes disponibles constitue un véritable langage de commandes, offrant des possibilités très étendues, au point qu'une comparaison entre CSH et WShell donnerait sans doute un résultat dépendant largement des préférences subjectives de l'utilisateur.
Les commandes
Vu le nombre des commandes offertes, il n'est évidemment pas question de les passer toutes en revue. Examinons les grandes catégories dans lesquelles on peut classer les commandes internes de CSH.
Les commandes de navigation dans les répertoires et de manipulation des fichiers
Ces commandes remplissent les mêmes fonctions que leurs homologues dc l'AmigaShell. Un certain nombre d'entre elles ont des abréviations, comme CP pour Copy, ou des sortes d'alias à deux lettres, comme LS pour Der, ou MV (move) pour Rename. Beaucoup de ces abréviations ne sont pas documentées, donc expérimentez.
Toutes les commandes ont des possibilités étendues au niveau de l'utilisation des jokers.
Il n'y a pas de commande List, ses fonctions sont normalement remplies par des options de la commande LS. Conservez toutefois votre commande List si vous souhaitez réaliser des scripts traitant des séries de fichiers en utilisant l'option Format de List. Je critique souvent indirectement les commandes de Commodore en montrant les avantages d'autres jeux de commandes ; certaines d'entre elles ont néanmoins leur attrait en offrant des possibilités uniques, comme celle que je viens de citer pour List. Un des intérêts de l'Amiga est la commodité avec laquelle on se constitue dans le répertoire C: le jeu de commandes que l'on préfère, à partir de diverses origines.
Il y a par contre des commandes puissantes comme Open, qui permet d'ouvrir jusqu'à dix fichiers et de les désigner comme source ou destination pour l'indirection de n'importe quelle commande. Par exemple :
| Open ram:toto w 2 |
Ouvrez le fichier "ram:toto" en écriture, avec l'identification 2.
| Echo bonjour > .2 |
Écrivez dans le fichier ouvert en n°2 la chaîne "bonjour".
| Close 2 Type ram:toto (ou CAT ram:toto) |
...affiche :
| bonjour |
C'est simple comme... bonjour, à part que l'exemple donné dans la doc ne marche pas, même dans la dernière version (voyez plus loin le texte sur la commande RPN). CSH ne se livre pas comme ça sans détour, il se mérite. Par contre, l'effort vaut la peine.
En effet, la commande Open avec le paramètre "r" va permettre d'aller lire un fichier ligne par ligne, comme avec la classique routine "getline" que l'on écrit à titre d'exercice en C. Voici un exemple :
Soit un fichier ram:tutu composé comme suit :
|
echo "bonjour" echo "erreur $i" |
La séquence...
|
Open ram:tutu r 2 set slt <.2 set errmsg <.2 Close 2 |
...va donner aux variables "slt" et "errmsg" respectivement les valeurs "bonjour" et "erreur $i". Ceci couplé aux nombreuses commandes de traitement des variables et de chaînes, et au fait que beaucoup de commandes acceptent comme paramètres des variables de substitution, ouvre des possibilités énormes. L'exemple ci-dessus suggère la possibilité de récupérer des messages d'erreurs redirigés vers un fichier en cours d'exécution d'un script, et de les traiter.
L'accès aux fichiers par "Open", tant en écriture qu'en lecture, se fait par lignes et de manière séquentielle non indexée.
Il y a aussi "FLTLower" et "FLTUpper" pour mettre tout un fichier en majuscules ou en minuscules, ou "Touch" pour mettre à jour les informations de date et d'heure relatives à un fichier.
Les commandes de branchement dans les scripts
A côté des classiques If, Endif, Label, etc., on trouve un GOTO, commande bien décriée, mais qui rend des services dans des cas précis, mais aussi Foreach, Forever, Forline, Fornum.
Nous y reviendrons dans le chapitre consacré aux variables.
Les commandes relatives aux variables
Comme AShell, CSH traite ses variables propres, avec les possibilités de substitution dont nous parlerons également dans le chapitre traitant des variables locales.
On y trouve :
- Aset, compatible avec la commande fort malencontreusement nommée Set dans l'Aztec.
- Set, qui permet d'attribuer une valeur à une variable.
- Input qui permet d'attribuer une valeur à une variable à partir du Stdin (la console par exemple) ou d'une indirection.
- Inc, qui permet de l'incrémenter (étonnant, non ?).
- Strhead, Strleft, Strlen, Strmid, Strright, Strtail qui placent dans des variables diverses parties de chaînes de caractères.
- Unset pour supprimer une ou plusieurs variables.
Parmi elles :
- History pour afficher l'historique des commandes.
- PS pour connaître le statut des processus DOS en cours.
- RPN pour faire des calculs en notation polonaise inversée (dans la doc est donné un exemple d'utilisation d'indirection dur RPN pour écrire directement le résultat d'un calcul dans un fichier ; la notation .CR censée ajouter un saut de ligne n'est absolument pas reconnue par la commande).
- Search, très puissante comme celle d'ARP.
- Info qui par contre est moins bonne que la commande d'origine.
- Path qui permet d'afficher les chemins de recherche d'AmigaDOS, mais pas de les modifier (!) ; il faudra donc garder dans C: la commande "Path" Commodore ou ARP, et l'appeler spécifiquement (quelle idée de mettre en interne une commande moins puissante que celle d'origine !).
- Window pour déterminer ou connaître les caractéristiques d'une fenêtre.
Ouvrez deux CLI, et dans chacun d'eux, lancez un Shell. Dans le premier, tapez "RXRec" suivi d'un nom quelconque, par exemple "rexx_csh" (c'est au demeurant le nom par défaut). Vous perdez la main, ce qui est normal, car ce Shell attend maintenant un message. Dans le second, tapez :
| RXSend rexx_csh "dir df0:" |
...et vous voyez la commande s'effectuer dans le premier Shell. Tapez ensuite :
| RXSend rexx_csh bye |
...et tout rentre effectivement dans l'ordre.
En conclusion de ce chapitre sur les commandes, on peut dire que CSH est nettement plus puissant qu'AShell et à fortiori qu'AmigaShell, et que l'on dispose d'un véritable langage de commandes. Ceci offre une possibilité similaire à celle qu'offre ARexx, qui est de pouvoir écrire de petits programmes en disposant d'une commodité équivalente à celle d'un interpréteur, puisque le résultat de la plupart des commandes peut être vérifié immédiatement à l'écran. Par ailleurs, il y a des manques et des défauts légers sans doute mais surprenants.
Les différences de syntaxe, les alias, les jokers
Le fait de disposer du jeu de commandes Commodore dans votre répertoire C: et du jeu des commandes internes de CSH présente quelques inconvénients, du fait des différences parfois notables des syntaxes.
CSH va chercher la commande à exécuter d'abord dans ses commandes internes, puis dans les commandes résidentes, puis dans le répertoire courant, puis dans les chemins propres à votre fenêtre AmigaShell, puis dans C:, et enfin dans le chemin du Shell en dernière analyse, les fichiers scripts en "automatic sourcing" (voir au chapitre des scripts). Par exemple, si vous voulez afficher le contenu de votre répertoire courant, vous tapez "Dir". Ça marche, mais la présentation n'est pas la même que celle de la commande classique. Pas grave. Par contre, imaginez que vous souhaitiez copier le contenu de votre tiroir Fonts:, avec tous ses sous-répertoires, dans RAM:. La syntaxe :
| Copy Fonts: RAM: all |
...vous gratifiera d'un message: "destination not a directory".
La syntaxe CSH est :
| Copy -r Fonts: RAM: |
De même, les jokers "#" n'étant pas reconnu, il faut utiliser "*" au lieu de "#?".
A ce propos, un lecteur m'a fait remarquer que le système de jokers de Commodore est plus puissant que le système "*" ou "*.*", car "#" signifie "n'importe quel nombre de fois le caractère qui suit", ce qui n'a pas d'équivalent dans les systèmes de jokers basés sur "*". Rendons à Commodore ce qui est à Commodore et merci à Alexandre Amortila pour cette précision.
Le système des jokers est celui d'Unix, c'est-à-dire :
- * remplace n'importe quel caractère ou suite de caractères.
- ? remplace un caractère.
- .../* déclenche une recherche "récursive" dans les sous-répertoires.
- ~ et ! sont un préfixe de négation.
- [] définit une classe pour un caractère.
- & placé au début d'une chaîne déclenche la demande d'une confirmation d'exécution de la commande à chaque occurrence.
- # similaire à celui de Commodore. Exemple : "k#a" trouvera "ka", "kaa", "kaaa", etc.
- (|) qui donne une fonction "ou". Exemple : "hel(lo|p)" trouvera "hello" et "help".
| Alias cstart "cd dh0:aztec/s; execute startup-sequence; cd dh0:aztec/exercices" |
...ceci peut remplacer un petit fichier script.
Bien sûr on peut passer un argument à Alias, la syntaxe est d'une beauté sophistiquée et glacée. Syntaxe :
| Alias name "%var [command string]" |
Exemple :
|
Alias slt "%nom echo Salut $nom yau de poêle" slt FRedChef |
...donne comme résultat :
| Salut FRedChef yau de poêle |
Lequel résultat est par conséquent insolite et grandiose.
L'édition de la ligne de commandes et l'historique
Le Shell original de Matt Dillon n'offrait rien en matière d'édition de lignes ni d'historique des commandes, Matt recommandait l'utilisation de ConMan. Les auteurs de CSH ont incorporé un certain nombre de fonctions dans ce but, ce qui ne les empêche pas de mentionner une précaution à prendre lors de l'utilisation de ConMan (utilisation du paramètre "-a" en lançant le Shell, pour désactiver les fonctions d'édition de ligne propres à CSH).
L'édition des commandes est classique au moyen des touches de curseur et d'une série de commandes de type "Ctrl-lettre" ; exemple :
- Ctrl-a fait passer du mode insertion de caractères au mode écrasement.
- Ctrl-D fait sortir du Shell.
- Ctrl-R réaffiche la ligne courante.
- Ctrl-X ou Ctrl-U (pour "undo") efface la ligne courante.
En ce qui concerne l'historique des commandes, on peut y naviguer grâce aux touches de curseur en combinaison avec la touche majuscules, et afficher cet historique. Mais dans ce domaine ConMan se révèle très supérieur en offrant par exemple le choix entre deux modes d'historique (historique strict, ou historique ne stockant pas deux fois la même commande) et la possibilité de sauver des historiques dans des fichiers.
Les améliorations de l'environnement de travail
Un Shell est là entre autres pour apporter certaines commodités qui rendent la vie plus facile. L'une d'elles est la possibilité d'utiliser des Pipes. Les Pipes de CSH sont d'utilisation simple, exemple :
| List | Sort | More |
...marche de la même manière que dans AShell.
On pourrait parler ici de l'existence de variables locales, mais je préfère traiter ce sujet au chapitre des scripts. Toutefois, CSH possède un certain nombre de variables propres, qui pour la plupart affectent directement l'environnement de travail, aussi allons-nous les passer en revue ici ; on leur donne une valeur par la commande "Set", on les remet à zéro par "Unset".
- _prompt, dans cette variable se trouve une chaîne de caractères qui définit l'invite ; elle peut contenir des séquences d'échappement pour modifier l'aspect du texte, et en y incluant la variable "%p" on obtient l'affichage du chemin courant.
- _history, nombre de lignes de l'historique.
- _debug, mode debug (commentaire de la doc : si vous osez).
- _verbose affiche les commandes d'un script au fil de leur exécution.
- _maxerr contient la valeur la plus haute des codes de sévérité d'erreur rencontrés.
- _lasterr contient le niveau de sévérité la dernière erreur exemple : commande Toto; message d'erreur "object not found ; _lasterr contient la valeur 20.
- _cwd contient le chemin du répertoire courant ; utile pour le retrouver car un programme peut changer le répertoire courant et CSH peut ne rien en savoir. La commande PWD restaure le contenu de _cwd à la valeur en cours.
- _path contient les chemins que suivra CSH pour trouver une commande externe.
- _insert définit le mode de frappe (insertion ou écrasement) ; CSH revient à ce mode à chaque frappe de la touche "à la ligne".
- _titlebar, contenu de la barre de titre de la fenêtre.
- _clinumber contient le numéro eu CLI (ou AmigaShell) courant.
Cet ensemble de variables permettent toutes les personnalisations désirables.
Enfin, victoire ! CSH permet de définir à la volée les touches de fonction F1 à F10 et "Shift-F1" à "Shift-F10" , de la manière la plus simple qui soit, par la commande "Set", exemple :
| Set F4 sys:utilities/xoper |
Malheureusement, cette possibilité disparaît en cas d'utilisation de ConMan.
Les scripts
Les fichiers scripts, en langage CSH "source files", constituent en fait de petits programmes composés d'instructions, principalement des commandes du Shell. Un fichier "source" s'exécute par la commande "Source", qui est l'équivalent de "Execute". Toutefois, "Source" permet de passer des arguments à un script via la variable _passed, sous la forme d'une chaîne que l'on pourra décortiquer à son aise au moyen des commandes "STRxxx" que nous avons citées précédemment. Pour exécuter un fichier "source" à la seule invocation de son nom, il suffit de lui donner le suffixe ".sh" qui joue alors le rôle de l'attribut "s" de l'AmigaShell.
Mais un langage de programmation voit son utilité réduite si l'on ne dispose pas de la possibilité d'utiliser des variables. C'est une des faiblesses de l'AmigaShell, et de WShell lorsque l'on ne lui accole pas ARexx (selon la règle qui dit que le sucre est un produit qui donne un mauvais goût au café quand on n'en met pas dedans).
Comme ASH, CSH permet l'utilisation de variables "locales" (par rapport aux variables d'environnement, comme celles décrites au chapitre précédent). Ces variables sont définies par l'instruction "Set", on peut leur donner comme valeur un nombre ou une chaîne de caractères. Une variable peut aussi être définie par son utilisation comme argument d'une commande. L'accès à la valeur d'une variable se fera en précédant son nom du signe "S".
Un exemple : syntaxe de la commande "Foreach" :
| Foreach [-v] varname (strings) command |
Exemple :
| Foreach i (a b c d) "Echo -n $i ; Echo "ha"" |
Résultat :
|
a ha b ha c ha d ha |
Explications :
- [-v] est un argument optionnel ; s'il est présent, la commande effectuée est affichée à chaque boucle.
- i, on a ici une définition implicite d'une variable arbitraire nommée "i" par un extraordinaire souci d'originalité. Elle prendra successivement la valeur de chacune des chaînes écrites entre les parenthèses.
- (a b c d), ces quatre chaînes n'ont chacune dans l'exemple qu'un seul caractère.
- "ECHO etc" la commande à effectuer à chaque boucle est à mettre, avec ses arguments, entre guillemets. Vous remarquez que CSH a une notion élargie de la commande, puisqu'on peut toujours en mettre plusieurs à la suite, en les séparant par des points-virgules.
- Echo -n $i affiche le contenu de "i", sans retour à la ligne.
- Echo "ha", le caractère d'échappement permet d'éviter la confusion entre les guillemets qui encadrent les deux commandes et ceux qui encadrent l'argument de la deuxième commande Echo. Ces derniers sont nécessaires pour que soit pris en compte l'espace qui précède le texte "ha".
Avec tout ça, on peut écrire des scripts, ou "source files" particulièrement puissants.
Un scrIpt écrit sous AmigaDOS est-il exécutable sous CSH ?
La réponse est, malheureusement : dans de nombreux cas, non. Il y a deux sources d'incompatibilité potentielle :
1. La passation de paramètres. Dans les scripts AmigaShell, les paramètres sont interprétés grâce à l'instruction ".KEY" (ou simplement ".K") à la suite de laquelle on trouve un ou plusieurs noms de paramètres, auxquels se substitueront, pour l'exécution du script, les chaînes écrites à la suite du nom du script lors de son invocation.
Dans les scripts CSH, l'ensemble de ces paramètres est transmis au script sous la forme d'une seule chaîne, que l'on récupère dans la variable "_passed", et que l'on doit ensuite décortiquer soi-même à l'aide des commandes de traitement des chaînes de caractères. C'est évidemment bien moins commode, sauf dans le cas où il n'y a qu'un paramètre.
2. La différence de syntaxe des commandes. Le problème vient en fait de ce que CSH, continu tous ses congénères (AmigaOS 2.0 compris), possède un certain nombre de commandes internes, ceci dans un but évident de rapidité d'accès. Logiquement, dans le but de satisfaire à cette exigence, les auteurs ont déterminé l'ordre de recherche d'une commande en privilégiant les commandes internes. Un effet pervers de cette disposition est que lorsqu'une commande (voir "Copy" sous CSH) souvent utilisée dans des scripts, a une syntaxe totalement incompatible, elle empêchera l'exécution d'un script écrit sous un autre Shell.
C'est là qu'on se dit que ça commence à ressembler à l'absence totale de souplesse du "COMMAND.COM" de MS-DOS (beuârk). Mais que vaut-il mieux, avoir une série de commandes résidentes d'office, ou devoir les mettre résidentes au prix d'une séquence de démarrage plus longue, ou du lancement d'un script ad hoc ?
Y a-t-il des remèdes ? Ou en d'autres termes, a-t-on une chance de pouvoir exécuter sous CSH des scripts AmigaShell sans avoir à les modifier ? En ce qui concerne le premier point, la réponse est évidemment non, dès qu'il y a passation de paramètres. Pour ce qui est des commandes "incompatibles", la réponse est tout aussi négative, et je ne vois malheureusement que deux approches possibles pour utiliser les scripts AmigaShell :
- Soit modifier le script en y remplaçant la commande incriminée par son homologue "compatible", affectée de
son chemin complet, ce qui est assez facile à faire avec n'importe quel éditeur : l'exécution du script s'en
trouvera quelque peu ralentie.
- Soit tout simplement sortir de CSH, ou encore ouvrir une fenêtre sous un autre Shell, pour exécuter le script. Ce n'est pas nécessairement une catastrophe, puisque CSH doit de toute manière être lancé à partir d'un shell existant.
Interface avec les programmes
A priori, vu la présence du port compatible ARexx, et moyennant la possession d'un éditeur adéquat, il y a tout ce qu'il faut pour écrire des scripts permettant de lancer une compilation à partir de l'éditeur, traiter les messages d'erreur et revenir automatiquement dans l'éditeur au point voulu.
Conclusion
Si vous utilisez toujours le Shell de Matt Dillon, réveillez-vous, installez CSH, ce sera toujours ça de fait et vous ne serez pas dépaysé. Mais j'espère que vous n'avez pas attendu cet article pour le faire !
CSH n'est ni aussi "léché" et bien documenté que WShell, ni aussi simple d'utilisation pour un habitué d'AmigaDOS non familier d'Unix, qu'AShell.
Toutefois, si vous cherchez quelque chose de très performant, pour les quelques francs d'une disquette DP, CSH fera votre affaire ; à moins que ma vue n'ait réellement baissé, les auteurs de CSH ne demandent aucune contribution. C'est vraiment un très bon outil.
|
