projman/hlp/fr/tcl/exec.htm

102 lines
14 KiB
HTML
Raw Normal View History

2015-10-19 13:27:31 +03:00
<HTML><HEAD>
<BASEFONT FACE="Times New Roman" SIZE="2" COLOR="#000000">
</HEAD>
<BODY>
<div><H3><b>exec&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Commandes Internes Tcl</b></H3></div>
<HR ALIGN="left">
<div><b>NOM</b></div><br>
<div ALIGN="LEFT" style="margin-left: 51px;">exec - Appelle un ou des sous-processus
</div><br>
<div><b>SYNTAXE</b></div><br>
<div ALIGN="LEFT" style="margin-left: 51px;"><b>exec </b>?<i>switches</i>? <i>arg </i>?<i>arg ...</i>?
</div><br>
<div><b>DESCRIPTION</b></div><br>
<div ALIGN="LEFT" style="margin-left: 51px;">Cette commande traite ses arguments comme la sp<73>cification d'ex<65>cution d'un ou plusieurs sous-processus. Les arguments prennent la forme d'un pipeline shell standard o<> chaque <i>arg</i> devient un mot d'une commande, et chaque commande distincte devient un sous-processus. </div>
<div ALIGN="LEFT" style="margin-left: 51px;">Si les arguments initiaux <20> <b>exec</b> commencent avec un tiret<b> </b>alors ils sont trait<69>s comme des commutateurs de ligne de commande et ne font pas partie du pipeline. Les commutateurs suivants sont couramment support<72>s:
<DL>
<DT><b>-keepnewline</b><br></DT><DD>Ins<EFBFBD>re un saut de ligne dans la sortie de pipeline. Normalement le saut de ligne sera effac<61>.
</DD>
<DT><b>--</b><br></DT><DD>Marque la fin des commutateurs. L'argument suivant sera trait<69> comme le premier <i>arg</i> m<>me s'il commence avec un tiret.
</DD>
</DL>
</div>
<div ALIGN="LEFT" style="margin-left: 51px;">Si un <i>arg</i> (ou paire d'<i>args</i>) a une des formes d<>crites ci-dessous alors il est utilis<69> par <b>exec</b> pour contr<74>ler les flux d'entr<74>e et de sortie dans le(s) sous-processus. Ces arguments ne seront pas transmis au(x) sous-processus. Sous les formes telles que &quot;&lt; <i>fileName</i>&quot;, <i>fileName</i> peut soit <20>tre dans un argument s<>par<61> de &quot;&lt;&quot; ou dans le m<>me argument sans espace (ex. &quot;&lt;<i>fileName</i>&quot;).
<DL>
<DT>|</DT><DD>S<EFBFBD>pare des commandes distinctes dans le pipeline. La sortie standard de la commande pr<70>c<EFBFBD>dente sera inject<63>e dans l'entr<74>e standard de la commande suivante.
</DD>
<DT><br>|&amp;</DT><DD>S<EFBFBD>pare des commandes distinctes dans le pipeline. L'ensemble sortie standard et erreur standard de la pr<70>c<EFBFBD>dante commande sera inject<63>e dans l'entr<74>e standard de la commande suivante. Cette forme de redirection surcharge les formes telles que 2&gt; et &gt;&amp;.
</DD>
<DT><br>&lt; <i>fileName</i></DT><DD>Le fichier design<67> par <i>fileName</i> est ouvert et utilis<69> comme l'entr<74>e standard pour le premi<6D>re commande dans le pipeline.
</DD>
<DT><br>&lt;@ <i>fileId</i></DT><DD><i>FileId</i> doit <20>tre l'identificateur pour un fichier ouvert, tel que la valeur de retour d'un pr<70>c<EFBFBD>dent appel de <A HREF="142.htm"><b>open</b></A>. Il est utilis<69> comme l'entr<74>e standard de la premi<6D>re commande dans le pipeline. <i>FileId</i> doit avoir <20>t<EFBFBD> ouvert en lecture.
</DD>
<DT><br>&lt;&lt; <i>value</i><br></DT><DD><i>Value</i> est transmise <20> la premi<6D>re commande comme son entr<74>e standard.
</DD>
<DT><br>&gt; <i>fileName</i></DT><DD>La sortie standard de la derni<6E>re commande est redirig<69>e sur un fichier nomm<6D> <i>fileName</i>, en <20>crasant son pr<70>cedent contenu.
</DD>
<DT><br>2&gt; <i>fileName</i></DT><DD>L'erreur standard de toute commande dans le pipeline est redirig<69>e sur un fichier nomm<6D> <i>fileName</i>, en <20>crasant son pr<70>cedent contenu.
</DD>
<DT><br>&gt;&amp; <i>fileName</i></DT><DD>L'ensemble sortie standard de la derni<6E>re commande et erreur standard de toute commande sont redirig<69>e sur un fichier nomm<6D> <i>fileName</i>, en <20>crasant son contenu pr<70>c<EFBFBD>dent .
</DD>
<DT><br>&gt;&gt; <i>fileName</i></DT><DD>La sortie standard de la derni<6E>re commande est redirig<69>e et ajout<75>e <20> la fin d'un fichier nomm<6D> <i>fileName</i>.
</DD>
<DT><br>2&gt;&gt; <i>fileName</i></DT><DD>L'erreur standard de toute commande dans le pipeline est redirig<69>e et ajout<75>e <20> la fin d'un fichier nomm<6D> <i>fileName</i>.
</DD>
<DT><br>&gt;&gt;&amp; <i>fileName</i></DT><DD>L'ensemble sortie standard de la derni<6E>re commande et erreur standard de toute commande sont redirig<69>es et ajout<75>es <20> la fin d'un fichier nomm<6D> <i>fileName</i>.
</DD>
<DT><br>&gt;@ <i>fileId</i></DT><DD><i>FileId</i> doit <20>tre l'identificateur d'un fichier ouvert, tel que la valeur de retour d'un pr<70>c<EFBFBD>dent appel de <A HREF="142.htm"><b>open</b></A>. La sortie standard de la derni<6E>re commande est redirig<69>e vers le fichier<i> </i><i>fileId</i>'s, qui doit avoir <20>t<EFBFBD> ouvert en <20>criture.
</DD>
<DT><br>2&gt;@ <i>fileId</i></DT><DD><i>FileId</i> doit <20>tre l'identificateur d'un fichier ouvert, tel que la valeur de retour d'un pr<70>c<EFBFBD>dent appel de <A HREF="142.htm"><b>open</b></A>. L'erreur standard de toute commande dans le pipeline est redirig<69>e vers le fichier<i> fileId</i>. Le fichier doit avoir <20>t<EFBFBD> ouvert en <20>criture.
</DD>
<DT><br>&gt;&amp;@ <i>fileId</i></DT><DD><i>FileId</i> doit <20>tre l'identificateur pour un fichier ouvert, tel que la valeur de retour d'un pr<70>c<EFBFBD>dent appel de <A HREF="142.htm"><b>open</b></A>. L'ensemble sortie standard de la derni<6E>re commande et erreur standard from toute commande sont redirig<69>e vers le fichier<i> fileId</i>. Le fichier doit avoir <20>t<EFBFBD> ouvert en <20>criture.
</DD>
</DL>
</div>
<div ALIGN="LEFT" style="margin-left: 51px;">Si la sortie standard n'a pas <20>t<EFBFBD> redirig<69>e alors la commande <b>exec</b> retourne la sortie standard de la derni<6E>re commande dans le pipeline. Si une des commandes dans le pipeline finit anormalement ou est <i>killed</i> ou suspendue, alors <b>exec</b> 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 <b>errorCode</b> contiendra des informations suppl<70>mentaires concernant la derni<6E>re terminaison anormale rencontr<74>e. Si une des commandes ecrit vers son fichier standard d'erreur et que cette erreur standard n'est pas redirig<69>e, alors <b>exec</b> 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 . </div>
<div ALIGN="LEFT" style="margin-left: 51px;">Si le dernier caract<63>re du r<>sultat ou du message d'erreur est un saut de ligne alors ce caract<63>re est normalement effac<61> du r<>sultat ou du message d'erreur. Ceci est coh<6F>rent par rapport aux autres valeurs de retour Tcl, qui ne finisssent normalement pas avec des sauts de ligne. N<>anmoins, si <b>-keepnewline</b> est sp<73>cifi<66> alors le saut de ligne est ajout<75>. </div>
<div ALIGN="LEFT" style="margin-left: 51px;">Si l'entr<74>e standard n'est pas redirig<69>e avec &quot;&lt;&quot; ou &quot;&lt;&lt;&quot; ou &quot;&lt;@&quot; alors l'entr<74>e standard pour la premi<6D>re commande dans le pipeline est prise de l'entr<74>e standard de l'application courante. </div>
<div ALIGN="LEFT" style="margin-left: 51px;">Si le dernier <i>arg</i> est &quot;&amp;&quot; alors le pipeline sera ex<65>cut<75> en arri<72>re-plan. Dans ce cas la commande <b>exec</b> renverra une liste dont les <20>l<EFBFBD>ments sont les identificateurs de processus pour tous les sous-processus dans le pipeline. La sortie standard de la derni<6E>re commande dans le pipeline ira dans la sortie standard de l'application si elle n'a pas <20>t<EFBFBD> redirig<69>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<69>e. </div>
<div ALIGN="LEFT" style="margin-left: 51px;">Le premier mot de chaque commande est interpr<70>t<EFBFBD> comme le nom de la commande; la substitution tilde est effectu<74>e, et si le r<>sultat ne contient pas de slashes alors les r<>pertoires dans la variable d'environnement PATH sont recherch<63>s pour un ex<65>cutable donn<6E>s. Si le nom contient un slash alors il doit se r<>f<EFBFBD>rer <20> un ex<65>cutable accessible du r<>pertoire courant. Aucune expansion &quot;glob&quot; ou autre substitutions shell-like ne sont effectu<74>es sur les arguments des commandes. <br>
</div><br>
<div><b>NOTES DE PORTABILITE </b></div><br>
<div ALIGN="LEFT" style="margin-left: 51px;">
<DL>
<DT><b>Windows</b> (toutes versions)</DT><DD>Lire ou <20>crire une socket, en
utilisant la notation &quot;<b>@ </b><i>fileId</i>&quot;, ne fonctionne pas. En essayant de lire une socket, une application DOS 16-bit se plantera et une application 32-bit retournera imm<6D>diatement avec fin-de-fichier. Quand ces deux types d'application ecrivent une socket, l'information est en fait envoy<6F>e <20> la console, si une est pr<70>sente, ou est <20>limin<69>e. <br>
La console texte Tk ne fournit pas de possibilit<69>s IO standard. Sous Tk, quand on redirige depuis l'entr<74>e standard, toutes les applications verront une fin-de-fichier imm<6D>diate; l'information redirig<69>e vers la sortie standard ou l'erreur standard sera <20>limin<69>e. <br>
Les slashes ou anti slashes sont accept<70>s comme s<>parateurs de chemin pour les arguments des commandes Tcl. A l'ex<65>cution d'une application, le nom de chemin sp<73>cifi<66> pour l'application peut aussi contenir des slashes ou des anti slashes comme s<>parateurs de chemin. Ayez <20> 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 <20> une application qui sp<73>cifie un nom de chemin avec des slashes ne seront pas automatiquement convertis en caract<63>res backslash. Si un argument contient des slashes comme s<>parateur de chemin, il peut ou ne peut pas <20>tre reconnu comme un nom de chemin, d<>pendant du programme. <br>
De plus, <20> 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 &quot;applba~1.def&quot; au lieu de of &quot;applbakery.default&quot;). <br>
Deux slashes ou backslashes ou plus dans un chemin se ref<65>rent <20> un chemin r<>seau. Par exemple, une simple concatenation du r<>pertoire racine <b>c:/</b> avec un sous r<>pertoire <b>/windows/system</b> donnera <b>c://windows/system</b> (deux slashes ensemble), qui se r<>f<EFBFBD>re <20> un point de montage appel<65> <b>system</b> sur la machine appel<65> <b>windows</b> (et le <b>c:/</b> est ignor<6F>), et n'est pas <20>quivalent <20> <b>c:/windows/system</b>, qui d<>crit un r<>pertoire sur l'ordinateur courant . La commande <b>file join</b> sera utilis<69>e pour concat<61>ner les composants de chemin.</DD>
<DT><br><b>Windows NT</b></DT><DD>Quand il tente d'ex<65>cuter une application, <b>exec</b> recherche en premier le nom comme il a <20>t<EFBFBD> sp<73>cifi<66>. Ensuite, dans l'ordre, <b>.com</b>, <b>.exe</b>, et <b>.bat</b> sont ajout<75>s <20> la fin du nom sp<73>cifi<66> et il recherche le nom plus l'extension. Si un nom de r<>pertoire n'a pas <20>t<EFBFBD> sp<73>cifi<66> comme partie du nom de l'application, les r<>pertoires suivants sont automatiquement recherch<63>s dans l'ordre pour tenter de localiser l'application: <br>
<div ALIGN="LEFT" style="margin-left: 110px;">Le r<>pertoire duquel l'ex<65>cutable Tcl a <20>t<EFBFBD> charg<72>. <br>
Le r<>pertoire courant. <br>
Le r<>pertoire syst<73>me Windows NT 32-bit. <br>
Le r<>pertoire syst<73>me Windows NT 16-bit. <br>
Le r<>pertoire home Windows NT. <br>
Les r<>pertoires list<73>s dans le chemin.</div> <br>
De mani<6E>re <20> ex<65>cuter les commandes shell internes comme <b>dir</b> et <b>copy</b>, l'appelant doit ajouter en t<>te de la commande &quot;<b>cmd.exe /c </b>&quot;.
</DD>
<DT><br><b>Windows 95</b></DT><DD>Quand il tente d'ex<65>cuter une application, <b>exec</b> recherche en premier le nom comme il a <20>t<EFBFBD> sp<73>cifi<66>. Ensuite, dans l'ordre, <b>.com</b>, <b>.exe</b>, et <b>.bat</b> sont ajout<75> <20> la fin du nom sp<73>cifi<66> et il recherche le nom plus l'extension. Si un nom de r<>pertoire n'a pas <20>t<EFBFBD> sp<73>cifi<66> comme partie du nom de l'application, les r<>pertoires suivants sont automatiquement recherch<63>s dans l'ordre pour tenter de localiser l'application: <br>
<div ALIGN="LEFT" style="margin-left: 110px;">Le r<>pertoire duquel l'ex<65>cutable Tcl a <20>t<EFBFBD> charg<72>. <br>
Le r<>pertoire courant. <br>
Le r<>pertoire syst<73>me Windows 95. <br>
Le r<>pertoire home Windows 95. <br>
Les r<>pertoires list<73>s dans le chemin. </div><br>
De mani<6E>re <20> ex<65>cuter les commandes shell internes comme <b>dir</b> et <b>copy</b>, l'appelant doit ajouter en t<>te de la commande &quot;<b>command.com /c </b>&quot;<br>
Une fois qu'une application DOS 16-bit a lu l'entr<74>e standard d'une console et quitt<74>, toutes les applications DOS 16-bit ex<65>cut<75>es ensuite verront l'entr<74>e standard comme d<>j<EFBFBD> ferm<72>e. Les applications 32-bit n'ont pas ce probl<62>me et s'ex<65>cuteront correctement, m<>me apr<70>s une application DOS 16-bit qui pense que l'entr<74>e standard est ferm<72>e. Il n'y a pas de correction connue de ce bug <20> ce jour . La redirection entre le p<>riph<70>rique <b>NUL:</b> et une application 16-bit ne fonctionne pas toujours. Quand on redirige de <b>NUL:</b>, certaines applications se planteront, d'autres emmetront un flux infini d'octets &quot;0x01&quot;, et d'autres obtiendront correctement une fin-de-fichier imm<6D>diate; ce comportement semble d<>pendre de quelque chose compil<69> dans l'application elle-m<>me. Quand la redirection vers <b>NUL:</b> est sup<75>rieure <20> 4K , quelques applications se planteront. Les probl<62>mes pr<70>c<EFBFBD>dents ne se produisent pas avec les applications 32-bit. <br>
Toutes les applications DOS 16-bit sont ex<65>cut<75>es de mani<6E>re synchrone. Toute entr<74>e standard d'un pipe vers une application DOS 16-bit est collect<63> dans un fichier temporaire; l'autre extr<74>mit<69> du pipe doit <20>tre ferm<72>e avant que l'application DOS 16-bit commence l'ex<65>cution. Toute sortie ou erreur standard d'une application DOS 16-bit vers un pipe est collect<63>e dans des fichiers temporaires; l'application doit se terminer avant que les fichiers temporaires soient redirig<69>s <20> l'<27>tape suivante du pipeline. Ceci est du <20> une correction d'un bug de Windows 95 dans l'impl<70>mentation des pipes, et est la mani<6E>re standard du shell DOS sous Windows 95 de g<>rer les pipes. <br>
Certaines applications, tel que <b>command.com</b>, ne seront pas ex<65>cut<75>es interactivement. Les applications qui acc<63>dent directement <20> la fen<65>tre Dos, au lieu de lire depuis leur entr<74>e standard et d'<27>crire sur leur sortie standard peut <20>chouer, planter Tcl, ou m<>me planter le syst<73>me si leur propre console ne leur est pas disponible.
</DD>
<DT><br><b>Macintosh</b></DT><DD>La commande <b>exec</b> n'est pas impl<70>ment<6E>e et n'existe pas sous Macintosh. </DD>
<DT><br><b>Unix</b></DT><DD>La commande <b>exec</b> est pleinement fonctionnelle et fonctionne comme d<>crit.
</DD>
</DL>
</div><br>
<div><b>VOIR EGALEMENT</b></div><br>
<div ALIGN="LEFT" style="margin-left: 51px;"><A HREF="142.htm">open</A>(n) </div>
<div>Derni<EFBFBD>re r<>vision: 7.6</div>
<br>
<br><div ALIGN="CENTER"><A HREF="index.htm"><b>Index</b></A>&nbsp;&nbsp;<A HREF="104.htm"><b>Pr<EFBFBD>c<EFBFBD>dent</b></A>&nbsp;&nbsp;<A HREF="106.htm"><b>Suivant</b></A>
</div>
</BODY></HTML>