2009-02-20 8 views
1

J'ai scénario NAnt qui dans le cadre de son projet appelle un fichier de commandes en utilisant la tâche suivante:Nant la création du fichier de redirection de cmd.exe appelé « programme » sur c: lecteur

<target name="makeplane"> 
    <exec program="C:\WINDOWS\system32\CMD.EXE" 
     commandline="/C ${make.file} &gt; ${make.log}"   
     verbose="false" 
     workingdir="${make.dir}" 
     basedir="${make.dir}">   
     </exec> 
    <delete> 
     <fileset basedir="c:\"> 
     <include name="program" /> 
     </fileset> 
    </delete> 
</target> 

Malheureusement je n'ai pas le contrôle au-dessus du contenu sur le fichier séquentiel et il vomit beaucoup d'ordures sur l'écran qui ne sert à rien dans le journal. Donc, pour contourner ce im redirigeant la sortie du fichier de chauve-souris dans un fichier texte à l'aide du

&gt; ${make.log} 

partie qui équivaut à « > log.txt ».

Cette redirection semble créer un fichier appelé "programme" sur le lecteur C et bousille toutes sortes de services et Windows ne l'aime généralement pas. Pour contourner ce problème, je supprime manuellement ce fichier après l'exécution du fichier bat. Le problème est que je dois maintenant exécuter une tâche similaire pour un autre projet entièrement et s'ils s'exécutent en même temps, le premier verrouillera le fichier appelé "programme" et le second échouera. Pas exactement une bonne situation pour l'intégration continue. J'ai cherché sur le net, mais parce que le fichier est appelé programme, je reçois toutes sortes de déchets. N'importe qui a eu des idées sur un travail autour. J'ai essayé le paramètre de sortie sur la tâche exec mais le problème reste le même.

Répondre

1

Habituellement, cela se produit parce que le script tente de créer un fichier avec un nom de fichier long avec l'espace dans ce (c:\program files dans votre cas), mais il n'utilise des guillemets autour du nom de fichier long.

+0

Doh, pourquoi n'ai-je pas pensé à cela plus tôt. – SecretDeveloper

3

Si le chemin d'accès au fichier contient des espaces, il est généralement conseillé d'entourer le chemin entre guillemets. Pour ce faire, vous pouvez utiliser l'entité &quot;.

Il semble que ce soit ce qui se passe dans votre situation particulière. Par conséquent, si vous changez votre exemple à ce qui suit, je pense que les choses devraient fonctionner comme prévu.

<target name="makeplane"> 
    <exec program="C:\WINDOWS\system32\CMD.EXE" 
     commandline="/C ${make.file} &gt; &quot;${make.log}&quot;"   
     verbose="false" 
     workingdir="${make.dir}" 
     basedir="${make.dir}">   
    </exec> 
</target> 
+0

+1 J'ai mis en place un correctif avant de poster, mais vous l'auriez corrigé avec cette réponse. – SecretDeveloper

0

Voici ce que j'ai fait. Je pense que c'est un peu plus propre pour les commandes complexes.

<property name="cmd.label" value="\${ss.previous.label}@$Project.SSPath" /> 
<echo message="Getting $Project.Name source code with label \${cmd.label}" /> 
<property name="cmd" value="&quot;\${tfs.root}\tf.exe&quot; get $Project.SSPath &quot;/version:L\${cmd.label}&quot; /force /recursive /noprompt"/> 
<exec program="cmd.exe" 
    workingdir="\${shadow.dir}" 
    failonerror="true" 
    verbose="true"> 
<arg value="/c" /> 
<arg value="&quot;\${cmd}&quot;" /> 
<arg value="> nul" /> 
</exec> 
Questions connexes