exec
La curiosité n’est pas un vilain défaut mais une qualité fondamentale.
exec - Appelle un ou des sous-processus
SYNTAXE
exec ?switches? arg ?arg ...?
DESCRIPTION
Cette commande traite ses arguments comme la spécification d'exécution d'un ou plusieurs sous-processus. Les arguments prennent la forme d'un pipeline shell standard où chaque arg devient un mot d'une commande, et chaque commande distincte devient un sous-processus.
Si les arguments initiaux à exec commencent avec un tiret alors ils sont traités comme des commutateurs de ligne de commande et ne font pas partie du pipeline. Les commutateurs suivants sont couramment supportés:
-keepnewline Insère un saut de ligne dans la sortie de pipeline. Normalement le saut de ligne sera effacé.
-- Marque la fin des commutateurs. L'argument suivant sera traité comme le premier arg même s'il commence avec un tiret.
Si un arg (ou paire d'args) a une des formes décrites ci-dessous alors il est utilisé par exec pour contrôler les flux d'entrée et de sortie dans le(s) sous-processus. Ces arguments ne seront pas transmis au(x) sous-processus. Sous les formes telles que "< fileName", fileName peut soit être dans un argument séparé de "<" ou dans le même argument sans espace (ex. "<fileName").
| Sépare des commandes distinctes dans le pipeline. La sortie standard de la commande précédente sera injectée dans l'entrée standard de la commande suivante.
|& Sépare des commandes distinctes dans le pipeline. L'ensemble sortie standard et erreur standard de la précédante commande sera injectée dans l'entrée standard de la commande suivante. Cette forme de redirection surcharge les formes telles que 2> et >&.
< fileName Le fichier désigné par fileName est ouvert et utilisé comme l'entrée standard pour le première commande dans le pipeline.
<@ fileId FileId doit être l'identificateur pour un fichier ouvert, tel que la valeur de retour d'un précédent appel de open. Il est utilisé comme l'entrée standard de la première commande dans le pipeline. FileId doit avoir été ouvert en lecture.
<< value Value est transmise à la première commande comme son entrée standard.
> fileName La sortie standard de la dernière commande est redirigée sur un fichier nommé fileName, en écrasant son précedent contenu.
2> fileName L'erreur standard de toute commande dans le pipeline est redirigée sur un fichier nommé fileName, en écrasant son précedent contenu.
>& fileName L'ensemble sortie standard de la dernière commande et erreur standard de toute commande sont redirigée sur un fichier nommé fileName, en écrasant son contenu précédent .
>> fileName La sortie standard de la dernière commande est redirigée et ajoutée à la fin d'un fichier nommé fileName.
2>> fileName L'erreur standard de toute commande dans le pipeline est redirigée et ajoutée à la fin d'un fichier nommé fileName.
>>& fileName L'ensemble sortie standard de la dernière commande et erreur standard de toute commande sont redirigées et ajoutées à la fin d'un fichier nommé fileName.
>@ fileId FileId doit être l'identificateur d'un fichier ouvert, tel que la valeur de retour d'un précédent appel de open. La sortie standard de la dernière commande est redirigée vers le fichier'' 'fileIds, qui doit avoir été ouvert en écriture.
2>@ fileId FileId doit être l'identificateur d'un fichier ouvert, tel que la valeur de retour d'un précédent appel de open. L'erreur standard de toute commande dans le pipeline est redirigée vers le fichier fileId. Le fichier doit avoir été ouvert en écriture.
>&@ fileId FileId doit être l'identificateur pour un fichier ouvert, tel que la valeur de retour d'un précédent appel de open. L'ensemble sortie standard de la dernière commande et erreur standard from toute commande sont redirigée vers le fichier fileId. Le fichier doit avoir été ouvert en écriture.
Si la sortie standard n'a pas été redirigée alors la commande exec retourne la sortie standard de la dernière commande dans le pipeline. Si une des commandes dans le pipeline finit anormalement ou est killed ou suspendue, alors exec renverra une erreur et le message d'erreur inclura la sortie du pipeline suivi par le message d'erreur décrivant la terminaison anormale; la variable errorCode contiendra des informations supplémentaires concernant la dernière terminaison anormale rencontrée. Si une des commandes écrit vers son fichier standard d'erreur et que cette erreur standard n'est pas redirigée, alors exec renverra une erreur; le message d'erreur inclura la sortie standard du pipeline, suivi par les messages au sujet de la terminaison anormale (si elle existe), suivi par la sortie d'erreur standard .
Si le dernier caractère du résultat ou du message d'erreur est un saut de ligne alors ce caractère est normalement effacé du résultat ou du message d'erreur. Ceci est cohérent par rapport aux autres valeurs de retour Tcl, qui ne finissent normalement pas avec des sauts de ligne. Néanmoins, si -keepnewline est spécifié alors le saut de ligne est ajouté.
Si l'entrée standard n'est pas redirigée avec "<" ou "<<" ou "<@" alors l'entrée standard pour la première commande dans le pipeline est prise de l'entrée standard de l'application courante.
Si le dernier arg est "&" alors le pipeline sera exécuté en arrière-plan. Dans ce cas la commande exec renverra une liste dont les éléments sont les identificateurs de processus pour tous les sous-processus dans le pipeline. La sortie standard de la dernière commande dans le pipeline ira dans la sortie standard de l'application si elle n'a pas été redirigée, et la sortie d'erreur de toutes les commandes dans le pipeline ira vers le fichier standard d'erreur de l'application sauf si elle est redirigée.
Le premier mot de chaque commande est interprété comme le nom de la commande; la substitution tilde est effectuée, et si le résultat ne contient pas de slashes alors les répertoires dans la variable d'environnement PATH sont recherchés pour un exécutable donnés. Si le nom contient un slash alors il doit se référer à un exécutable accessible du répertoire courant. Aucune expansion "glob" ou autre substitutions shell-like ne sont effectuées sur les arguments des commandes.
NOTES DE PORTABILITÉ
Windows (toutes versions) Lire ou écrire une socket, en utilisant la notation "@ fileId", ne fonctionne pas. En essayant de lire une socket, une application DOS 16-bit se plantera et une application 32-bit retournera immédiatement avec fin-de-fichier. Quand ces deux types d'application écrivent une socket, l'information est en fait envoyée à la console, si une est présente, ou est éliminée. La console texte Tk ne fournit pas de possibilités IO standard. Sous Tk, quand on redirige depuis l'entrée standard, toutes les applications verront une fin-de-fichier immédiate; l'information redirigée vers la sortie standard ou l'erreur standard sera éliminée. Les slashes ou anti-slashes sont acceptés comme séparateurs de chemin pour les arguments des commandes Tcl. A l'exécution d'une application, le nom de chemin spécifié pour l'application peut aussi contenir des slashes ou des anti slashes comme séparateurs de chemin. Ayez à l'esprit, néanmoins, que la plupart des applications Windows acceptent des arguments avec seulement des slashes comme délimiteurs d'option et seulement des backslashes dans les chemins. N'importe quels arguments à une application qui spécifie un nom de chemin avec des slashes ne seront pas automatiquement convertis en caractères backslash. Si un argument contient des slashes comme séparateur de chemin, il peut ou ne peut pas être reconnu comme un nom de chemin, dépendant du programme. De plus, à l'appel d'une application 16-bit DOS ou Windows 3.X, tout les noms de chemin doivent utiliser le format de chemin court(ex, en utilisant "applba~1.def" au lieu de of "applbakery.default"). Deux slashes ou backslashes ou plus dans un chemin se référent à un chemin réseau. Par exemple, une simple concaténation du répertoire racine c:/ avec un sous répertoire /windows/system donnera c://windows/system (deux slashes ensemble), qui se réfère à un point de montage appelé system sur la machine appelé windows (et le c:/ est ignoré), et n'est pas équivalent à c:/windows/system, qui décrit un répertoire sur l'ordinateur courant . La commande file join sera utilisée pour concaténer les composants de chemin.
Windows NT Quand il tente d'exécuter une application, exec recherche en premier le nom comme il a été spécifié. Ensuite, dans l'ordre, .com, .exe, et .bat sont ajoutés à la fin du nom spécifié et il recherche le nom plus l'extension. Si un nom de répertoire n'a pas été spécifié comme partie du nom de l'application, les répertoires suivants sont automatiquement recherchés dans l'ordre pour tenter de localiser l'application: Le répertoire duquel l'exécutable Tcl a été chargé. Le répertoire courant. Le répertoire système Windows NT 32-bit. Le répertoire système Windows NT 16-bit. Le répertoire home Windows NT. Les répertoires listés dans le chemin. De manière à exécuter les commandes shell internes comme dir et copy, l'appelant doit ajouter en tête de la commande "cmd.exe /c ".
Windows 95 Quand il tente d'exécuter une application, exec recherche en premier le nom comme il a été spécifié. Ensuite, dans l'ordre, .com, .exe, et .bat sont ajouté à la fin du nom spécifié et il recherche le nom plus l'extension. Si un nom de répertoire n'a pas été spécifié comme partie du nom de l'application, les répertoires suivants sont automatiquement recherchés dans l'ordre pour tenter de localiser l'application: Le répertoire duquel l'exécutable Tcl a été chargé. Le répertoire courant. Le répertoire système Windows 95. Le répertoire home Windows 95. Les répertoires listés dans le chemin. De manière à exécuter les commandes shell internes comme dir et copy, l'appelant doit ajouter en tête de la commande "command.com /c " Une fois qu'une application DOS 16-bit a lu l'entrée standard d'une console et quitté, toutes les applications DOS 16-bit exécutées ensuite verront l'entrée standard comme déjà fermée. Les applications 32-bit n'ont pas ce problème et s'exécuteront correctement, même après une application DOS 16-bit qui pense que l'entrée standard est fermée. Il n'y a pas de correction connue de ce bug à ce jour . La redirection entre le périphérique NUL: et une application 16-bit ne fonctionne pas toujours. Quand on redirige de NUL:, certaines applications se planteront, d'autres émettront un flux infini d'octets "0x01", et d'autres obtiendront correctement une fin-de-fichier immédiate; ce comportement semble dépendre de quelque chose compilé dans l'application elle-même. Quand la redirection vers NUL: est supérieure à 4K, quelques applications se planteront. Les problèmes précédents ne se produisent pas avec les applications 32-bit. Toutes les applications DOS 16-bit sont exécutées de manière synchrone. Toute entrée standard d'un pipe vers une application DOS 16-bit est collecté dans un fichier temporaire ; l'autre extrémité du pipe doit être fermée avant que l'application DOS 16-bit commence l'exécution. Toute sortie ou erreur standard d'une application DOS 16-bit vers un pipe est collectée dans des fichiers temporaires; l'application doit se terminer avant que les fichiers temporaires soient redirigés à l'étape suivante du pipeline. Ceci est du à une correction d'un bug de Windows 95 dans l'implémentation des pipes, et est la manière standard du shell DOS sous Windows 95 de gérer les pipes. Certaines applications, tel que command.com, ne seront pas exécutées interactivement. Les applications qui accèdent directement à la fenêtre Dos, au lieu de lire depuis leur entrée standard et d'écrire sur leur sortie standard peut échouer, planter Tcl, ou même planter le système si leur propre console ne leur est pas disponible.
Macintosh La commande exec n'est pas implémentée et n'existe pas sous Macintosh Classic, par contre, elle est disponible pour Mac OS X.
Unix La commande exec est pleinement fonctionnelle et fonctionne comme décrit.
VOIR ÉGALEMENT