J'ai la classe java suivante et un fichier batch.
testc.java :
import java.io.BufferedReader;
import java.io.File;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.Map;
public class testc {
public static void main(String[] mainargs) {
System.out.println("Java class initiated");
try {
String line;
ArrayList<String> args = new ArrayList<String>();
String script = "script-util.bat";
args.add(script);
ProcessBuilder pb = new ProcessBuilder(args);
Map<String, String> env = pb.environment();
System.out.println("Starting batch file");
Process process = pb.start();
InputStream is = process.getInputStream();
BufferedReader reader = new BufferedReader(new InputStreamReader(is));
while (null != (line = reader.readLine())) {
System.out.println("OUT: " + line);
}
System.out.println("Waiting for complete exit");
int returnCodeW = process.waitFor();
int returnCodeE = process.exitValue();
System.out.println("returnCodeW: " + returnCodeW);
System.out.println("returnCodeE: " + returnCodeE);
}
catch (Throwable t) {
System.out.println("Exception caught");
}
}
}
Le contenu de script-util.bat est juste une ligne,
cas 1 :
exit /B 0
cas 2 :
exit /B 2
cas 3 :
exit 0
cas 4 :
exit 2
cas 5 :
rem exit 0
Sortie pour "java testc" avec un fichier batch ayant le contenu du cas 1 lorsqu'il est exécuté dans une invite de commande non évidée :
c:\javatest2>java testc
Java class initiated
Starting batch file
OUT:
OUT: c:\javatest2>exit /B 0
Waiting for complete exit
returnCodeW: 1
returnCodeE: 1
La sortie pour le cas 5 renvoie également le code 1 au lieu de 0. La sortie pour tous les autres cas, ou tous les cas lorsqu'ils sont exécutés depuis le même répertoire de travail dans une invite de commande élevée, renvoie le code de niveau d'erreur correct.
Ma question est de savoir pourquoi le code de sortie renvoie 1 au lieu de 0 s'il n'est pas exécuté en tant qu'administrateur ?
Environnement : Windows Server 2016 x64, JDK 1.8
Edit : Ce problème semble être spécifique à l'environnement. Une installation de Windows Server 2016 10.0.14393 utilisant JDK 1.8 u151 se comporte comme ci-dessus alors qu'une autre installation de la même construction ne le fait pas. Quoi qu'il en soit, ceci n'est pas attendu sous aucun environnement.