Mecredi 30 novembre 2022

Le fichier de construction (Makefile) : cinq nouveaux modules

• Modification des options :
  • Ajout de l’option -Wall qui permet de repérer immédiatement de nombreuses erreurs.
  • -Wwrite-strings et -Wcast-qual augmentent l’intérêt de const.
  • Remplacement de -ll par -lfl pour l’édition de liens avec Flex (visiblement plus portable).
• Modification des modules (un module = un source .c + un entête .h) :
  • Renommages (pour avoir tout en anglais) :
    • les fichiers « Analyse » ont été renommés en « CmdParsing » ;
    • le module « Affichage » a été renommé en « Display ».
  • Trois modules ont été créés par extraction du code d’un module préexistant :
    • du module Shell a été extrait le module Expression : types pour les expressions et leurs paramètres ;
    • du module Evaluation a été extrait le module Proc : gestion des processus et des signaux ;
    • du module Evaluation a été extrait le module Jobs : gestion des tâches de fond.
  • Ajout de deux modules :
    • InternalCommands : commandes spéciales prises en charge par Mini-Shell ;
    • ArgsParsing (module le plus long) : gestion des variables ($var, var=), des commandes entre accents graves (`cmd`) et des métacaractères (*?).
• Une nouvelle règle me permet de créer facilement une archive des sources du projet, que l’enseignant m’a interdit de diffuser…

Comme vous le verrez dans cette présentation, j’ai modifié tous les fichiers du projet. Je n’en ai épargné aucun.

Le fichier d’analyse syntaxique CmdParsing.l

Objectif principal des modifications : permettre à l’analyseur d’accepter davantage de caractères sans altérer sa visée initiale de fournir des paramètres prêts à être utilisés.

• Définition des symboles YY_NO_UNPUT et YY_NO_INPUT pour éviter deux avertissements inutiles à propos de fonctions inutilisées.
• COMMENT : absorption des # en début de paramètre et de tout ce qui les suit pour les ignorer.
• Chaque paramètre est une succession de mots collés formés de l’une des trois manières suivantes :
  • ARG_NOQUOTES : des caractères autres que \n\t `"'<>&|;()\, ainsi que des \ (caractères d’échappement) chacun suivi par un caractère quelconque ;
  • ARG_BACKTICKS : une suite de caractères entre accents graves ;
  • ARG_DBLQUOTES : une suite de caractères entre guillemets doubles ("), comprenant éventuellement des guillemets du même type échappés par \, et dans lesquels les \ doivent être échappés ;
  • ARG_SINGLEQUOTES : une suite de caractères entre guillemets simples ('), dans laquelle il n’est pas nécessaire d’échapper les caractères (mais qui ne peut pas comprendre de ').
• L’analyseur supprime les guillemets et les caractères d’échappement pour fournir le paramètre.
• L’opérateur de redirection est analysé pour en tirer des informations :
  • type : entrée, sortie ou ajout ;
  • numéro du descripteur de fichier à rediriger ;
  • redirection vers fichier ou vers descripteur de fichier (si & à la fin).
• Correction d’une fuite de mémoire : après yy_create_buffer, il faut appeler yy_delete_buffer (je l’ai identifié avec valgrind).

L’analyseur d’origine n’acceptait que deux formes de paramètres (même si on les collait, c’était considéré comme plusieurs paramètres) :

• une suite de caractères parmi -.$%=/\*?, les 26 lettres majuscules et minuscules ASCII et les chiffres de 0 à 9 ;
• une suite de caractères quelconques avec un guillemet simple ou double au tout début et à la toute fin (ces guillemets étant enlevés du résultat).

Remarques (défauts par rapport à Bash) :

• impossible d’écrire des commandes multilignes ;
• impossible d’échapper les paires d’accents graves `...` dans un paramètre ;
• la suppression des guillemets à ce niveau fait qu’il est impossible pour l’interpréteur de savoir s’il y a eu des guillemets et lesquels ;
• l’analyseur n’accepte pas les parenthèses non échappées après $ (donc impossible de faire $(cmd) et $(( calcul ))) ;
• la suppression des caractères d’échappement et des guillemets à ce niveau a pour conséquence que les caractères des variables d’environnement $ et = et les métacaractères * et ? seront toujours interprétés ;
• les \ sont toujours considérés comme des caractères d’échappement (même entre guillemets), et sont donc supprimés à moins d’être précédés d’un autre \ ;
• à cause du système d’analyse récursive, entre accents graves il est nécessaire d’utiliser un double échappement (par exemple \\\" à la place de \") ;
• on ne peut pas fournir une entrée avec << (mais on peut utiliser cat |) ;
• contrairement à Bash, on accepte &>& (ça, ce n’est pas un défaut).

Faites vos tests ! Mettez en forme vos paramètres et regardez ce qui apparait entre crochets. Puis comparez avec le comportement de Bash.

echo # abc
echo#
echo \# "#"
echo "#"
echo \
echo \\
echo 1 2 1\ 2 "1 2" 1" "2
echo `
echo "
echo "`" "\""
echo `"` `\` `\"`
echo \\\"\& '\\"&'
...
      

Le fichier d’analyse syntaxique CmdParsing.y

• Diminution de la priorité de l’opérateur de séquençage ; afin qu’il ait une priorité plus basse que tous les autres opérateurs (comportement identique à celui de Bash). À l’origine, il avait une priorité inférieure à & et identique à && et ||. Ainsi la ligne :

  echo; echo && echo &
              

  était interprétée comme suit :

  ((echo; echo) && echo) &
              

  et est maintenant interprétée comme :

  echo; ((echo && echo) &)
              

  Je me suis rendu compte du problème après avoir codé la fonction linearizeExpr du module Display, qui fait apparaitre les parenthèses.
• Changement des types de données de argsList et de singleArg pour pouvoir les allouer dynamiquement (et ainsi dépasser les limites de 50 paramètres par commande et 500 caractères par paramètre).
• Ajout de la structure pour les redirections. Elle est déjà initialisée dans l’analyse lexicale, par conséquent à cet endroit on a moins de code.
• Utilisation de littéraux composés (plutôt que d’une fonction un peu superflue) pour la construction des objets de type Expression. La macro alloc appelle malloc et memcpy.

Défauts par rapport à Bash : les redirections de descripteurs de fichiers sont évaluées de droite à gauche (comme s’il y avait des parenthèses) et doivent forcément être après tous les paramètres (alors que Bash les accepte n’importe où dans la liste des paramètres).

Expérience : essayez echo; echo && echo & sans puis avec la modification de priorité de ;.

Le module principal : Shell

Dans l’entête :

• Une petite structure shell (de type Shell) regroupe quelques paramètres liés au shell au premier plan, notamment les paramètres fournis au programme. Ces données sont parfois modifiées temporairement, notamment lors de l’utilisation de la commande source.
• La fonction yyparse_string est déclarée (utilisée par InternalCommands et ArgsParsing).
• Une fonction commandExecution contient les instructions de la boucle principale (elle est appelée par la commande source).
• Le booléen interactiveMode est déclaré (utilisé par Proc).
• Un environnement de saut et un booléen permettent de gérer le Ctrl+C durant l’exécution de readline.

Dans le fichier source :

• Davantage de variables globales :

• On encadre l’appel à readline :

• On n’ajoute pas les lignes vides dans l’historique :

• L’initialisation :
  • on enregistre les paramètres donnés au programme (utilisés par ArgsParsing et par la commande shift) ;
  • pour savoir si le shell est interactif, il suffit d’appeler isatty(STDIN_FILENO) ;
  • on appelle une fonction d’initialisation (pour faire des sigaction).

• La boucle principale appelle la fonction commandExecution. Elle comporte quelques nouveautés :
  • l’affichage de l’arbre de l’expression est conditionné par une variable du shell ;
  • après l’évaluation, la fonction evaluationFinished est appelée (elle vérifie les tâches de fond) ;
  • en cas d’erreur de syntaxe, on retient le code de statut 2.

• L’arrêt du Shell est fait avec un saut (sauf dans le cas des processus enfants) :

• À la fin, on affiche un retour à la ligne dans tous les cas pour plus de propreté (Bash ne le fait pas), et on renvoie la dernière valeur de statut :

Le module Expression : types pour les expressions et leurs paramètres

J’ai déplacé dans ce module ce qui concerne le type Expression.

• Parmi les types d’expression, les 5 types de redirection ont été fusionnés en un seul, et il y a une autre énumération pour le type de redirection. 2 sur 5 ont été supprimés : redirection de la sortie d’erreur et redirection simultanée de la sortie standard et de la sortie d’erreur. Ils sont maintenant gérés par le type « redirection de la sortie » (REDIR_OUT).
• Le type ArgsList permet de gérer les listes de paramètres plus efficacement : le nombre de paramètres est précalculé dans le champ len et la taille allouée est stockée car on alloue toujours des gros blocs. argc et argv sont des synonymes de argsList.len et argsList.args.
• La petite structure redirect fournit toutes les informations nécessaires pour une redirection.

Le module Proc : gestion des processus et des signaux

Dans l’entête :

• Des fonctions pour gérer les processus enfants sont fournies.
• La fonction d’initialisation principale est déclarée.
• Le booléen isMainProc est déclaré : il est à true dans le processus principal, tous les processus enfants l’initialisent à false.
• Un booléen permettant de savoir si une interruption a été déclenchée est déclaré.

Dans le fichier source :

• On a deux variables globales :

• À l’initialisation, en mode interactif, on prévoit de traiter les interruptions (Ctrl+C, SIGINT) et d’ignorer les arrestations (Ctrl+Z, SIGTSTP ; signaux du TTY : SIGTTIN, SIGTTOU). Puis on isole le processus du shell dans son propre groupe de processus (setpgid), et on donne à ce groupe le contrôle du terminal (tcsetpgrp) :

• Lors d’une interruption, on affiche un retour à la ligne. Dans le cas où on était dans readline, on redémarre juste avant readline (fuite de mémoire ?). Sinon, on lève un drapeau (isInterrupted).

• Quand on crée un processus enfant, on rétablit les traitements par défaut pour les signaux d’interruption et d’arrêt. Si le processus est un enfant direct du processus principal et qu’il doit être mis à l’arrière-plan, on le met dans son propre groupe de processus.

• L’enregistrement des processus enfants stoppés dans la liste des tâches de fond se fait dans la fonction checkChild, mais seulement pour le processus principal et seulement en mode interactif. Dans les autres cas, on demande au processus enfant de reprendre immédiatement. Remarque : la fonction peut prendre en paramètre soit une commande (son texte) soit une expression.

• Lorsqu’un processus enfant est terminé, on ne le supprime plus immédiatement de la liste des tâches de fond : on marque simplement la tâche comme étant terminée. Attention : si le processus enfant a reçu un SIGINT, wait renvoie -1 et met la valeur EINTR dans la variable globale errno, et le processus demeure en tant que zombie. Dans ce cas, on continue bien évidemment les wait. (Dans les autres cas où wait renvoie -1, elle donne une autre valeur à errno.) currentJob est une variable utilisée pour stocker quelques informations sur la dernière tâche au premier plan.

• Une fonction permet d’attendre la fin ou la mise en suspens d’une tâche. À moins d’être dans le processus principal en mode interactif, la mise en suspens ne termine pas la fonction : lorsque le processus est mis en suspens, on le relance immédiatement, et on attend sa fin. Remarque : endOfChild exécute waitpid aussi mais ce n’est pas un problème. Si on est dans le processus principal, alors on met le processus enfant dans son propre groupe et on lui donne le terminal, puis le shell reprend le contrôle du terminal à la fin.

Défaut par rapport à Bash : envoyer SIGTERM sur un processus enfant stoppé n’arrête pas ce dernier immédiatement.

Essayez de lancer des commandes de toutes sortes et de les interrompre ou les stopper avec Ctrl+C ou Ctrl+Z.

Le module Evaluation : évaluation des expressions

Dans l’entête :

• Une constante détermine la valeur à ajouter aux signaux lorsqu’on les renvoie comme statut.
• Deux nouvelles fonctions sont déclarées.

Dans le fichier source :

• Si une interruption a eu lieu, on renvoie toujours 130 sans faire d’autre action :

• Dans le cas des expressions vides, le statut précédent est préservé :

• Quand un processus enfant est stoppé, on renvoie 148 :

• Dans le cas BG, on vérifie si le processus lancé en arrière-plan s’est terminé avant la fin de l’exécution d’addJob ; la fonction addJob prend une description de la commande en paramètre :

• Le cas SIMPLE est nettement complexifié (et donc porte très mal son nom) :
  • On commence par remplacer les noms de variables (commençant par $) par la valeur de celles-ci dans les paramètres (putEnvValues).
  • Ensuite, on récupère la sortie des commandes écrites dans les paramètres (entre accents graves ``), pour la mettre à la place de ces commandes (putCmdsOutput).
  • Ensuite, on effectue les affectations aux variables d’environnement indiquées par les premiers paramètres. On garde les paramètres restants. S’il n’y en a pas, on quitte immédiatement (en renvoyant la valeur 0).
  • Si une interruption a déjà eu lieu (pendant putCmdsOutput), on quitte immédiatement (toujours en renvoyant 130).
  • Ensuite, les métacaractères sont traités. On obtient une nouvelle liste de paramètres.
  • Ensuite, on cherche si la commande à exécuter est une commande interne (findCommandFct). Si oui, on exécute cette commande (sans fork) et on quitte. On fournit à la commande une copie des pointeurs vers les paramètres, et non pas directement ces pointeurs au cas où ils seraient modifiés (ce qui peut arriver si un fichier lu par la commande source utilise la commande shift, et aurait pour conséquence que la mémoire utilisée pour stocker les paramètres ne serait pas libérée).
  • Si la commande est kill, on remplace les désignations de tâches (%1, %2, %3…) par l’identifiant du processus (putJobPidsInArgs).
  • Si l’exécution de la commande échoue, c’est erreur 127 pour fichier introuvable et 126 pour accès interdit.
  • On finit classiquement avec waitForChild.

• Dans le cas PIPE, on met la tâche dans un fork principal, et dedans, on fait un fork pour chaque côté du tube (pour pouvoir gérer leur arrêt et leur reprise), puis on attend la fin des deux et on renvoie le code de retour du deuxième (la fonction de traitement de SIGCHLD dans le fork principal est éliminée pour éviter les ennuis) :

• Les redirections de descripteurs de fichiers sont traitées par une fonction :
  Cette fonction prend en charge de nombreuses fonctionnalités :
  • Par défaut, elle redirige le paramètre fourni (defaultFD). Si l’opérateur de redirection commence par &, elle rajoute STDERR_FILENO. Si l’opérateur commence par un nombre, c’est le descripteur de fichier correspondant qui est redirigé.
  • Dans le nom de fichier fourni, on remplace les noms de variables par leurs valeurs et les commandes entre accents graves par leur sortie (comme dans le cas SIMPLE).
  • Les métacaractères dans le nom de fichier sont traités. Le résultat doit être un seul paramètre, sinon déclaration d’erreur et abandon.
  • Le fichier vers lequel rediriger est ouvert. Si l’opérateur de redirection se termine par &, le nom de fichier est interprété comme un numéro de descripteur de fichier. Si l’ouverture du fichier échoue, déclaration d’erreur et abandon.
  • On fait les redirections dans un fork et on termine de façon classique. Attention au cas où le numéro de descripteur de fichier utilisé pour ouvrir le fichier est le numéro à rediriger.

• Après l’évaluation, on détecte les processus stoppés ou continués et on affiche leur nouvel état. Puis on affiche l’état des processus terminés et on les supprime de la liste. Enfin, on baisse le drapeau isInterrupted. Sans la fonction evaluationFinished, on pouvait mettre ces instructions à la fin d’evaluateExpr en les conditionnant par expr == shell.parsedExpr.

Défauts par rapport à Bash :

• De très nombreux fork sont effectués, de sorte qu’en cas de Ctrl+Z, ce soit vraiment toute la commande qui soit stoppée. Bash semble ne faire de fork que pour le cas SIMPLE, et chaque processus enfant commence par se configurer en fonction de l’expression qui l’entoure ; cette configuration est donc enregistrée par Bash pour être appliquée au dernier moment, tandis que Mini-Shell n’enregistre rien, il applique directement.
• Le changement de valeurs de variables d’environnement en début de commande est persistant. Pour l’éviter, il suffit de rajouter &; fg en fin de commande.
• Exécuter une commande mise entre parenthèses puis la stopper (Ctrl+Z) peut conduire à stopper plusieurs tâches distinctes (alors que Bash met tout dans la même tâche dans ce cas-là). Impossible à corriger puisque l’analyseur ne transmet pas les parenthèses.
• Lorsqu’une tâche de fond nouvellement lancée s’arrête ou se termine en un instant, Bash le détecte immédiatement et l’affiche tout de suite, alors que Mini-Shell ne l’affiche qu’après la commande suivante.

Amusez-vous ! Regardez ce qui se passe quand vous exécutez les commandes suivantes, et quand vous les interrompez ou les stoppez, ou les exécutez en arrière-plan.

ls | (sleep 3 && cat) | cat -n
echo >& 3 3> file.txt
...
      

Le module Jobs : gestion des tâches de fond

J’ai déplacé les fonctions de gestion des tâches de fond dans ce module.

Dans l’entête :

• Énumération pour les statuts des tâches de fond.
• Dans la structure Job, ajout de trois champs :
  • le texte de la commande (limité à 255 caractères…) ;
  • le statut de la tâche ;
  • la valeur renvoyée par la tâche à sa fin.

• Un tableau fournit les descriptions textuelles des états de tâches :

• Une variable currentJob est prévue pour être utilisée comme tampon à divers endroits (avant, il y avait juste un tampon pour la valeur de retour) :

• Quatre fonctions permettent de parcourir la liste des tâches de fond (pour ne pas avoir à se soucier de la structure de données sous-jacente ; au départ, j’utilisais un tableau statique) :

• Une fonction sert à afficher les informations sur une tâche (c’est elle qui utilise jobStateTexts) :

• La fonction addJob prend en charge de nouvelles informations et affiche le numéro, l’identifiant de processus et le texte de la commande de la tâche nouvellement ajoutée (seulement dans le processus principal, hors duquel les tâches de fond ont toutes le numéro 0 pour être différenciées) :

• Une nouvelle fonction remplace dans une liste de paramètres les numéros de tâches de fond (préfixé par %) par leur identifiant de processus (utilisée pour la commande kill) :

Différences par rapport à Bash :

• l’affichage de l’état d’une tâche est différent (Bash a beaucoup plus de 4 expressions) ;
• lorsqu’une tâche est stoppée, deux lignes sont affichées : une montrant l’identifiant de processus (affichage de addJob) et une indiquant l’état « Stopped » ;
• les informations sur les tâches de fond sont montrées même lorsque le shell n’est pas interactif.

Le module Display : affichage des expressions

• Davantage d’informations sont affichées pour les redirections :

• Une fonction pour transformer une expression en commande (afin de caractériser les tâches de fond) a été ajoutée :

Il y a bien entendu des défauts par rapport à Bash dans la linéarisation des expressions : les parenthèses ne sont plus telles quelles (elles sont rajoutées artificiellement pour le respect de l’ordre des opérations reçu) et les caractères d’échappement (barres obliques inversées et guillemets : \"') ne sont pas remis.

Le module InternalCommands : commandes spéciales

Dans l’entête :

• Un synonyme simple de pointeur vers une fonction de commande est déclaré. Une fonction de commande a simplement le même prototype que la fonction main.
• Une seule fonction est déclarée : elle renvoie la fonction correspondant au nom de commande donné, s’il y en a une.

Dans le fichier source :

• Il y a quatre fonctions de commandes très simples :
  Pour changer de répertoire de travail, il suffit d’appeler la fonction chdir. Une fois que c’est fait, la commande cd met à jour la variable PWD en exécutant une commande.
• Il y en a trois pour les tâches de fond (leur fonctionnement n’est pas sorcier) :

• Enfin, il y a la fonction de la commande source, qui exécute le contenu d’un script dans la session :
  La fonction commence par ouvrir le fichier donné en paramètre et par remplacer les paramètres de programme globaux par les paramètres locaux. Ensuite, elle lit des lignes de taille arbitraire (en doublant la taille de son tampon chaque fois que c’est nécessaire) et les exécute grâce aux mêmes appels que dans la boucle principale de la fonction main du module Shell. À la fin, les anciens paramètres globaux ainsi que la précédente expression analysée sont restaurés, et le fichier est fermé.
• Les commandes sont stockées dans un tableau de structures contenant leur nom et l’adresse de la fonction (par ordre lexicographique de nom de commande), et la fonction pour trouver la fonction d’une commande fait une recherche dichotomique dans ce tableau :

Quelques différences par rapport à Bash :

• Il y a beaucoup moins de commandes. En particulier :
  • il n’y a pas de commande read (mais à la place de read var, on peut simplement écrire var=`cat`) ;
  • je n’ai pas pris la peine de recoder les commandes pour lesquelles il y a déjà un programme installé qui fonctionne très bien (echo, true, false, test/[, pwd ; on peut voir la différence en tapant par exemple echo --version), même s’il était explicitement proposé dans le sujet de recoder echo.
• La commande shift affiche plus de messages d’erreurs que celle de Bash (cas de 0 et de nombres trop grands).
• La commande bg traite toujours les tâches de fond dans l’ordre de leurs numéros, pas dans l’ordre dans lequel ils sont indiqués dans les paramètres (afin d’éviter un copier-coller comme c’est fait pour jobs). De plus, bg sans paramètre traite toutes les tâches de fond (alors que Bash maintient une pile pour savoir quelle tâche traiter par défaut).
• La commande fg n’accepte pas les paramètres inutiles. De plus, en l’absence de paramètre, elle prend simplement la dernière tâche de fond (alors que Bash maintient une pile pour savoir quelle tâche traiter par défaut).
• Les commandes acceptent autre chose que des nombres là où elles attendent des nombres. Ainsi, écrire un nombre suivi par autre chose dans un paramètre fonctionne, et autre chose qu’un nombre est lu comme un 0.
• Les commandes de gestion des tâches de fond n’acceptent pas % comme préfixe des numéros de tâche.

Maintenant, il est temps de s’amuser avec ces commandes ! Mini-Shell n’affiche pas automatiquement le répertoire de travail ; vous devez utiliser la commande pwd pour obtenir le chemin.

Le module ArgsParsing : traitement avancé des commandes

On peut voir dans l’entête que le module propose quatre fonctions : l’une (setEnvValues) lit dans les paramètres des instructions pour modifier l’environnement, les trois autres transforment les paramètres.

La fonction putEnvValues remplace les désignations de variables (commençant par $) par les valeurs de ces variables. Les variables spéciales ?, #, $, * et @ sont prises en charge ; leur contenu est calculé la première fois qu’elles sont vues dans le texte du paramètre. À part ça, les paramètres fournis au shell, à indices numériques, sont pris en charge. Et les variables d’environnement classiques sont prises en charge, grâce à la fonction getenv. La fonction accepte que le nom de la variable soit entouré d’accolades. La présence d’espaces dans la valeur d’une variable ne conduit pas à découper le paramètre (c’est équivalent au comportement de Bash lorsqu’on met la désignation de la variable entre guillemets doubles).

La fonction putCmdsOutput remplace les commandes entre accents graves par la sortie de ces commandes. Une seule commande est exécutée à la fois, elle peut être interrompue mais pas stoppée (comportement identique à celui de Bash). Seulement 1023 caractères au maximum sont récupérés. La présence d’espaces dans la sortie ne conduit pas à découper le paramètre (c’est équivalent au comportement de Bash lorsqu’on met les accents graves et la commande entre guillemets doubles).

La fonction setEnvValues est la plus courte du module : elle parcourt les paramètres tant que chaque paramètre vu commence par un nom de variable correct suivi du signe =. Elle renvoie le nombre de paramètres ainsi lus.

Enfin, la fonction expandWildCards utilise la fonction récursive addCorrespondingPaths pour remplacer les métacaractères * et ? par les noms de fichiers/dossiers qui correspondent au motif, s’il y en a. Cette fois, le nombre de paramètres augmente potentiellement, c’est pourquoi la fonction prend en paramètre la liste de tous les paramètres, et renvoie une toute nouvelle ArgsList. La fonction fnmatch vue au TD 2 est utilisée. Si un paramètre génère plusieurs paramètres, ces derniers sont triés lexicographiquement (sinon, ils sont ordonnés n’importe comment).

Quelques défauts par rapport à Bash :

• Comme nous l’avons vu, les désignations de variables et les commandes entre parenthèses ne conduisent jamais à découper un paramètre, c’est toujours comme si c’était entre guillemets doubles.
• Les crochets [], les accolades {} et les tildes ~ ne sont pas traités de façon particulière.
• On ne peut pas indiquer entre accolades après le nom d’une variable comment la formater.
• Il y a des limites : seules 64 désignations de variables au maximum par paramètre sont remplacées par leur valeur, et seuls 1023 caractères au maximum de la sortie de chaque commande entre accents graves sont récupérés.
• Les tableaux (en tant que type de variables) ne sont pas pris en charge.

À l’attaque !

var=truc
echo $var
var=`echo A`
echo $var*
echo $$ $# $*
cat > truc.sh
echo $$ $# $*
echo $var2
[Ctrl+D]
var2=machin . truc.sh a b c
var2=machin sh truc.sh -s d e f
var2=machin ./Shell g h i < truc.sh
cat | var2=machin sh -s j k l
echo $var2 $# $*
[Ctrl+D]
...
      

C’est la fin ! Merci ! N’hésitez pas à poser des questions et à rapporter des anomalies !