Notes sur le Bourne Shell des UNIX

Dans la continuité du précédent message, la section 2.2.3, rappel que la barre oblique inversée (backslash) n’est pas toujours un caractère d’échappement ; dans une chaîne délimitée par des guillemets doubles, elle n’est un caractère d’échappement que quand elle est suivie de $ ou ` ou " ou \ ou un saut de ligne.

Exemple de piège à éviter :



On comprend mieux avec cet exemple plus simple mais de moindre intérêt pratique :



Il ne faut pas échapper ce qu’il est inutile d’échapper, au lieu d’être un échappement inutile, ça laisse les deux caractères.

D’après 2.8.2, les codes d’erreurs sont comme suit :

• 1 à 125 : erreur d’expansion ou de redirection.
• 126 : commande non‑exécutable (ex. droit d’accès, bit exécutable non positionné, …)
• 127 : commande non‑trouvée.
• 129 à 255 : commande terminée par un signal.

128 ne semble pas défini et 0 est évidemment pour l’absence d’erreur.

À la section 2.9.1, on apprend que les redirections peuvent se placer avant une commande, aussi bien que après comme on a le plus souvent l’habitude. Exactement, les éventuels redirections et assignations de variables apparaissent ensemble avant un commande dans n’importe quel ordre.

Si comme vous le savez probablement, on peut écrire ceci :


Au même endroit que l’assignation de la variable, même s’il est bien moins fréquent de le voir, on peut aussi avoir une redirection, comme ceci :


Qui est équivalent à :


Ceci ne s’applique pas aux commandes composées décrites à la section 2.9.4 :



Une redirection appliquée à une commande composée, s’applique à toutes les commandes de la commande composée, excepté pour les commandes ayant leur propre redirection. À 2.9.5, on apprend que ce type de redirection avec les commandes composées, s’applique aussi aux corps des fonctions ; les corps des fonctions sont en effet un cas particulier de commandes composées.

Encore dans la section 2.9.1, on apprend que l’assignation d’une variable précédant une commande, affecte ou pas l’environnement courant, selon que la commande qui la suit, est une commande prédéfinie du shell ou pas.

Si la commande est une commande externe, l’environnement n’est pas modifié (l’assignation n’est exportée que pour la commande), comme dans le premier cas de l’exemple plus bas. Si la commande est une commande prédéfinie du shell, l’environnement est modifié, comme dans le second cas de l’exemple plus bas. Quand la commande est une fonction, il n’est pas spécifié si l’environnement est modifié ou pas, comme expliqué plus loin.



À la même section 2.9.1, on apprend que en cas d’assignation de variable précédant une commande invoquant une fonction, l’état de la variable après l’appel de la fonction, n’est pas défini. Plus brièvement, après l’exécution de la fonction, la variable peut retrouver son ancienne valeur ou garder la valeur qui lui été assignée dans la commande d’appel de la fonction, ça dépend de l’implémentation du shell.

Exemple :



L’implémentation de Sh que j’utilise, conserve la valeur de la variable, mais on ne peut pas le tenir pour garanti.

Si une commande prédéfinie est implémentée comme une fonction, la commande est quand‑même considérée comme prédéfinie, pas comme une fonction.

Toujours d’après 2.9.1, sur les redirections : si comme il est courant de le voir, l’affectation d’une variable, non‑suivie d’une commande, modifie la variable dans l’environnement courant, il n’en va pas de même d’une redirection, qui comme rappelé dans l’avant‑précédent message, peut apparaitre là où une affectation de variable peut apparaitre. Quand elle apparait sous cette forme, une redirection ne redirige pas le flux de l’environnement courant, elle ne s’applique que dans un sous‑shell créé pour l’occasion, et qui finalement ne fait rien (ou je ne vois pas comment). Pour que la redirection s’applique dans l’environnement courant, il faut la faire précéder de exec. Dans ce cas particulier, exec ne remplace pas le shell courant.

Exemple :

À la section 2.9.2, on apprend que l’opérateur de négation logique, “ ! ”, que l’on voit fréquemment dans les expressions de test comme “ if [ ! … ]; then … ”, peut aussi s’utiliser pour les commandes en dehors d’une expression de test. Le statut de sortie renvoyé est alors soit 0 soit 1 : 0 quand la commande s’est terminé avec un statut différent de 0, et 1 quand la commande s’est terminé avec un statut égal à 0.

Exemple :

À la section 2.9.4, on voit que l’expression conditionnelle d’un “ if ”, d’un “ while ” ou d’un “ until ”, peut être une liste composée, en soulignant bien une liste. Comme le statut d’une liste composée est le statut de sa dernière commande, alors le résultat de l’expression dépend de la dernière commande.

Exemple :


Les points‑virgule peuvent être remplacés par des sauts de ligne, y compris dans l’expression conditionnelle.

À la section 2.9.5, quatre détails importants sur les fonctions.

Les fonctions et les variables, résident dans deux espaces de noms distincts, c’est à dire qu’une variable et une fonction peuvent avoir le même nom, sans que ça ne pose de problème :



Le corps d’une fonction suit la syntaxe d’une commande composée (qui peut être une commande simple), c’est à dire que les accolades ne sont pas toujours nécessaires :



Mais si le corps est une liste composée (ce qui est différent d’une commande composée), les accolades sont nécessaires :



Comme vous le savez probablement déjà, le « paramètre » $0 d’une fonction, reste le nom du script, pas celui de la fonction.

Il est rappelé qu’une fonction s’utilise comme une commande, ce qui signifie qu’une fonction peut être exécutée en arrière plan, comme avec une commande externe. Dans ce cas, comme avec une commande externe, la fonction est exécutée dans un sous‑shell.

Exemple :

À la section 2.10.2, mais ne pas s’en préoccupez plus que nécessaire, il est rappelé que les accolades et le point d’exclamation, sont des mots réservés, pas des opérateurs. Ça peut être important pour appliquer la grammaire du langage du shell, car les contextes où un opérateur peut être reconnu, ne sont pas les mêmes que les contextes où un mot réservé peut être reconnu.

À 2.13.1, deux notes importantes sur les expression régulières dans le shell. L’une de ces deux notes me semble s’appliquer aux chaînes de caractères en général ; ça concerne Unicode.

Les expressions régulières du shell n’ont pas la même syntaxe que les expressions régulière habituelles. Elles supportent quand‑même les ensemble de caractères, comme dans “ [abcde] ”, y compris la négation d’un ensemble de caractère, excepté que le symbole utilisé pour signifié la négation n’est pas “ ^ ” mais “ ! ”, probablement pour raison d’uniformité avec le reste de la syntaxe du langage du shell. La spécification dit que si “ ^ ” est utilisé pour signifier la négation d’un ensemble de caractères, alors le résultat n’est pas défini (c’est à dire variable selon les implémentations de Sh).

Exemple :



L’implémentation de Sh que j’utilise, interprète “ ^ ” comme “ ! ”, mais on ne peut pas compter dessus.

Une autre chose à noter et qui s’applique apparemment aux chaînes de caractères en général, est que les expressions régulières du shell, s’appliquent sur la chaîne d’octets représentant les caractères, pas sur les caractères eux‑mêmes. Cela signifie que le shell n’interprète pas les encodages Unicode. Ce n’est pas dit explicitement dans la spécification, ou alors je l’ai manqué, mais c’est probablement ce qui explique que la substitution renvoyant la longueur d’une chaîne de caractères, renvoi la longueur en octets au lieu de la longueur en caractères. Je précise que la longueur en octets dans l’exemple ci‑dessous, est pour UTF‑8.

Exemple :



UTF‑8 encode les caractères du second cas, sur deux octets chacun, la chaîne de quatre caractères fait huit octets de long, et la substitution donnant la longueur renvoi « 8 ».

C’est une lacune. Il faut penser que quand POSIX a été créé, Unicode et UTF‑8 n’existaient pas encore.