Linux - Commande Unix: exec

exec - invoque les sous-processus

Synopsis

exec? commutateurs ? se disputer ? arg … ?

La description

Cette commande traite ses arguments comme la spécification d'un ou plusieurs sous-processus à exécuter. Les arguments prennent la forme d’un pipeline shell standard où chaque se disputer devient un mot d'une commande et chaque commande distincte devient un sous-processus.

Si les arguments initiaux àexec Commencer avec- ils sont ensuite traités comme des commutateurs de ligne de commande et ne font pas partie de la spécification du pipeline. Les commutateurs suivants sont actuellement pris en charge:

-keepnewline

Conserve une fin de ligne dans la sortie du pipeline. Normalement, un retour à la ligne final sera supprimé.

--

Marque la fin des commutateurs. L'argument suivant celui-ci sera traité comme le premier se disputer même si ça commence par un-.

Si un se disputer (ou paire de se disputer 's) a l'une des formes décrites ci-dessous, il est utilisé parexec contrôler le flux des entrées et des sorties parmi les sous-processus. De tels arguments ne seront pas transmis au (x) sous-processus. Dans des formes telles que `` < nom de fichier '' nom de fichier peut être soit dans un argument séparé de `` '' ', soit dans le même argument sans espace intermédiaire (c'est-à-dire nom de fichier '').

|

Sépare les commandes distinctes dans le pipeline. La sortie standard de la commande précédente sera transmise à l'entrée standard de la commande suivante.

|&

Sépare les commandes distinctes dans le pipeline. La sortie standard et l'erreur standard de la commande précédente seront toutes deux acheminées vers l'entrée standard de la commande suivante. Cette forme de redirection remplace les formes telles que 2> et> &.

< nom de fichier

Le fichier nommé par nom de fichier est ouvert et utilisé comme entrée standard pour la première commande du pipeline.

<@ fileId

FileId doit être l'identifiant d'un fichier ouvert, tel que la valeur de retour d'un précédent appel àouvrir. Il est utilisé comme entrée standard pour la première commande du pipeline. FileId doit avoir été ouvert pour la lecture.

<< valeur

Valeur est passé à la première commande en tant qu'entrée standard.

> nom de fichier

La sortie standard de la dernière commande est redirigée vers le fichier nommé nom de fichier , écrasant son contenu précédent.

2> nom de fichier

L'erreur standard de toutes les commandes du pipeline est redirigée vers le fichier nommé nom de fichier , écrasant son contenu précédent.

>& nom de fichier

La sortie standard de la dernière commande et l’erreur standard de toutes les commandes sont redirigées vers le fichier nommé nom de fichier , écrasant son contenu précédent.

>> nom de fichier

La sortie standard de la dernière commande est redirigée vers le fichier nommé nom de fichier , y ajoutant plutôt que de l'écraser.

2>> nom de fichier

L'erreur standard de toutes les commandes du pipeline est redirigée vers le fichier nommé nom de fichier , y ajoutant plutôt que de l'écraser.

>>& nom de fichier

La sortie standard de la dernière commande et l’erreur standard de toutes les commandes sont redirigées vers le fichier nommé nom de fichier , y ajoutant plutôt que de l'écraser.

>@ fileId

FileId doit être l'identifiant d'un fichier ouvert, tel que la valeur de retour d'un précédent appel àouvrir. La sortie standard de la dernière commande est redirigée vers fileId Le fichier, qui doit avoir été ouvert pour l'écriture.

2>@ fileId

FileId doit être l'identifiant d'un fichier ouvert, tel que la valeur de retour d'un précédent appel àouvrir. L'erreur standard de toutes les commandes du pipeline est redirigée vers fileId Le dossier de. Le fichier doit avoir été ouvert pour l'écriture.

>&@ fileId

FileId doit être l'identifiant d'un fichier ouvert, tel que la valeur de retour d'un précédent appel àouvrir. La sortie standard de la dernière commande et l’erreur standard de toutes les commandes sont redirigées vers fileId Le dossier de. Le fichier doit avoir été ouvert pour l'écriture.

Si la sortie standard n’a pas été redirigée, laexec La commande retourne la sortie standard de la dernière commande du pipeline. Si une des commandes du pipeline se termine anormalement ou si elle est tuée ou suspendue,exec renverra une erreur et le message d'erreur inclura la sortie du pipeline suivi de messages d'erreur décrivant les terminaisons anormales; lacode d'erreur variable contiendra des informations supplémentaires sur la dernière terminaison anormale rencontrée. Si l’une des commandes écrit dans son fichier d’erreur standard et que cette erreur standard n’est pas redirigée,exec retournera une erreur; le message d'erreur comprendra la sortie standard du pipeline, suivie de messages sur les terminaisons anormales (le cas échéant), suivis de la sortie d'erreur standard.

Si le dernier caractère du résultat ou du message d'erreur est une nouvelle ligne, il est normalement supprimé du résultat ou du message d'erreur. Ceci est cohérent avec les autres valeurs de retour Tcl, qui ne se terminent pas normalement par des nouvelles lignes. Toutefois, si-keepnewline est spécifié, le retour à la ligne final est conservé.

Si l'entrée standard n'est pas redirigée avec «<» ou «<<» ou «<@» », l'entrée standard de la première commande du pipeline est extraite de l'entrée standard actuelle de l'application.

Si le dernier se disputer est "&" alors le pipeline sera exécuté en tâche de fond. Dans ce cas, leexecLa commande retournera une liste dont les éléments sont les identificateurs de processus pour tous les sous-processus du pipeline.La sortie standard de la dernière commande du pipeline ira à la sortie standard de l'application si elle n'a pas été redirigée, et la sortie d'erreur de toutes les commandes du pipeline ira au fichier d'erreur standard de l'application à moins qu'elle ne soit redirigée.

Le premier mot de chaque commande est pris comme nom de commande; Une substitution tilde est effectuée sur celui-ci. Si le résultat ne contient pas de barre oblique, les répertoires de la variable d'environnement PATH sont recherchés pour un exécutable portant le nom donné. Si le nom contient une barre oblique, il doit faire référence à un exécutable accessible à partir du répertoire en cours. Aucune extension "glob" ou autre substitution semblable à un shell n'est effectuée sur les arguments des commandes.

Problèmes de portabilité

les fenêtres (toutes les versions)

Lire ou écrire dans un socket en utilisant le ``@ fileId '' notation, ne fonctionne pas. Lors de la lecture d'un socket, une application DOS 16 bits se bloque et une application 32 bits renverra immédiatement avec la fin du fichier. Lorsque l'un ou l'autre type d'application écrit sur un socket, les informations sont plutôt envoyées à la console, si celle-ci est présente ou est ignorée.

Le widget texte de la console Tk ne fournit pas de capacités IO standard réelles. Sous Tk, lors de la redirection à partir de l'entrée standard, toutes les applications verront une fin de fichier immédiate; les informations redirigées vers la sortie standard ou l'erreur standard seront ignorées.

Les barres obliques inverses ou inverses sont acceptées comme séparateurs de chemin pour les arguments des commandes Tcl. Lors de l'exécution d'une application, le nom de chemin spécifié pour l'application peut également contenir des barres obliques inverses ou ascendantes en tant que séparateurs de chemin. Gardez toutefois à l'esprit que la plupart des applications Windows acceptent les arguments avec des barres obliques comme séparateurs d'option et des barres obliques inverses uniquement dans les chemins. Les arguments d'une application qui spécifient un nom de chemin d'accès avec des barres obliques ne seront pas automatiquement convertis pour utiliser le caractère barre oblique inverse. Si un argument contient des barres obliques comme séparateur de chemin, il peut ou non être reconnu comme nom de chemin, en fonction du programme.

De plus, lorsque vous appelez une application DOS ou Windows 3.X 16 bits, tous les noms de chemins doivent utiliser le format de chemin court et crypté (par exemple, en utilisant "applba ~ 1.def" au lieu de "applbakery.default" ).

Deux barres obliques ou plus dans une ligne ou plus se rapportent à un chemin réseau. Par exemple, une simple concaténation du répertoire racinec: / avec un sous-répertoire/ windows / system va céderc: // windows / system (deux barres obliques ensemble), qui fait référence au point de montage appelésystème sur la machine appeléeles fenêtres (et lec: / est ignoré) et n’équivaut pas àc: / windows / system, qui décrit un répertoire sur l’ordinateur actuel. lejointure de fichier La commande doit être utilisée pour concaténer les composants du chemin.

Windows NT

Lorsque vous essayez d'exécuter une application,exec recherche d'abord le nom tel qu'il a été spécifié. Puis, dans l'ordre,.com, .EXE, et.chauve souris sont ajoutés à la fin du nom spécifié et recherche le nom le plus long. Si aucun nom de répertoire n'a été spécifié dans le nom de l'application, les répertoires suivants sont automatiquement recherchés dans l'ordre lors de la tentative de localisation de l'application:

Le répertoire à partir duquel l'exécutable Tcl a été chargé.Le répertoire en cours.Répertoire système Windows NT 32 bits.Répertoire système Windows NT 16 bits.Le répertoire de base Windows NT.Les répertoires listés dans le chemin.

Afin d’exécuter les commandes internes du shell telles quedir etcopie, l'appelant doit précéder ``cmd.exe / c'' à la commande souhaitée.

Windows 95

Lorsque vous essayez d'exécuter une application,exec recherche d'abord le nom tel qu'il a été spécifié. Puis, dans l'ordre,.com, .EXE, et.chauve souris sont ajoutés à la fin du nom spécifié et recherche le nom le plus long. Si aucun nom de répertoire n'a été spécifié dans le nom de l'application, les répertoires suivants sont automatiquement recherchés dans l'ordre lors de la tentative de localisation de l'application:

Le répertoire à partir duquel l'exécutable Tcl a été chargé.Le répertoire en cours.Le répertoire système Windows 95.Répertoire de base Windows 95.Les répertoires listés dans le chemin.

Afin d’exécuter les commandes internes du shell telles quedir etcopie, l'appelant doit précéder ``command.com / c'' à la commande souhaitée.

Une fois qu'une application DOS 16 bits a lu l'entrée standard à partir d'une console puis s'est fermée, toutes les applications DOS 16 bits exécutées par la suite verront l'entrée standard déjà fermée. Les applications 32 bits n'ont pas ce problème et s'exécutent correctement même après qu'une application DOS 16 bits pense que l'entrée standard est fermée. Il n'y a pas de solution connue à ce bug pour le moment.

Redirection entre leNUL: périphérique et une application 16 bits ne fonctionne pas toujours. Lors de la redirection deNUL:, certaines applications peuvent se bloquer, d’autres obtiendront un flux infini d’octets «0x01» et d’autres obtiendront une fin de fichier immédiate; le comportement semble dépendre de quelque chose compilé dans l'application elle-même. Lorsque vous redirigez plus de 4K ou plus versNUL:, certaines applications vont se bloquer. Les problèmes ci-dessus ne se produisent pas avec les applications 32 bits.

Toutes les applications DOS 16 bits sont exécutées de manière synchrone. Toutes les entrées standard d’un canal vers une application DOS 16 bits sont rassemblées dans un fichier temporaire; l'autre extrémité du tuyau doit être fermée avant que l'application DOS 16 bits ne commence à s'exécuter.Toute sortie standard ou erreur d'une application DOS 16 bits vers un canal est collectée dans des fichiers temporaires; l'application doit se terminer avant que les fichiers temporaires ne soient redirigés vers la prochaine étape du pipeline. Cela est dû à une solution de contournement pour un bogue Windows 95 dans l'implémentation de canaux et à la façon dont le shell DOS standard de Windows 95 traite lui-même les canaux.

Certaines applications, telles quecommand.com, ne doit pas être exécuté de manière interactive. Les applications qui accèdent directement à la fenêtre de la console, au lieu de lire à partir de leur entrée standard et d'écrire sur leur sortie standard, peuvent échouer, bloquer Tcl ou même accrocher le système si leur propre fenêtre de console privée ne leur est pas accessible.

Macintosh

leexec La commande n'est pas implémentée et n'existe pas sous Macintosh.

Unix

leexec La commande est entièrement fonctionnelle et fonctionne comme décrit.

Voir également

erreur (n), ouverte (n)

Mots clés

exécuter, pipeline, redirection, sous-processus

Important: Utilisez le homme commande ( % homme ) pour voir comment une commande est utilisée sur votre ordinateur.