JDK-4255453 : win95 Runtime.exec() backslash quoting requirements are inconsistent with 98/NT
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_95
  • CPU: generic,x86
  • Submitted: 1999-07-20
  • Updated: 1999-09-01
  • Resolved: 1999-09-01
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Description
It appears that the quoting requirements for backslash are inconsistent between
Windows95, Windows98, and WindowsNT.  In some cases, the backslash is
interpreted so we must add extra "\" for later processing and in other cases it
is not.  This causes difficulties in setting environment variables for calling
Runtime.exec() in code which must run on all three platforms.  

In the following example, java.net.InetAddress.getLocalHost() requires windir
(for 95 and 98) or SystemRoot (for NT) to be set.  If the environment variable
is not not defined properly then the DNS lookup will fail and an
UnknownHostException will be thrown.  Please refer to the comments within the
code for details on which backslash quoting convention is required for each
platform.

STEPS TO REPRODUCE:
1.  $ javac QuoteBackslash.java
2.  $ javac GetLocalHost.java
3.  $ java QuoteBackslash
    [ modify declaration of "env" for different platforms as necessary ]

FILE: QuoteBackslash.java

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class QuoteBackslash {
    public static void main(String [] args) {
 	String [] cmd = {"l:\\jdk1.3\\win32\\bin\\java",
			 "-classpath",
			 ".",
 			 "GetLocalHost"};

	// 95 - ok
	//String [] env = {"windir=c:\\windows"};
	// 95 - not ok
	String [] env = {"windir=c:\\\\windows"};

	// 98 - not ok???
	//String [] env = {"windir=c:\\windows"};
	// 98 - ok
	//String [] env = {"windir=c:\\\\windows"};

	// NT - ok
	//String [] env = {"SystemRoot=c:\\winnt"};
	// NT - ok
	//String [] env = {"SystemRoot=c:\\\\winnt"};

	Process p = null;
	try {
	    p = Runtime.getRuntime().exec(cmd, env);
	    //p = Runtime.getRuntime().exec(cmd);
	    int exitCode = p.waitFor();

	    String line;

	    BufferedReader in = new BufferedReader(new InputStreamReader(p.getInputStream()));
	    while ((line = in.readLine()) != null)
		System.out.println(line);
	    in.close();

	    BufferedReader err = new BufferedReader(new InputStreamReader(p.getErrorStream()));
	    while ((line = err.readLine()) != null)
		System.out.println(line);
	    err.close();

	    //System.out.println("*** exit code: " + exitCode);
	} catch (InterruptedException e) {
	    if (p != null)
		p.destroy();
	} catch (IOException e) {
	    e.printStackTrace();
	}
    }
}

FILE: GetLocalHost.java

import java.net.*;

public class GetLocalHost {
    static InetAddress addr;

    public static void main(String args[]) throws Exception {
        addr = InetAddress.getLocalHost();
        System.out.println("ADDR: " + addr);
    }
}

OUTPUT (win95):

// "windir=c:\\windows"
[I:/work/bug/runtime] l:/java/jdk1.3/win32/bin/java QuoteBackslash
ADDR: kaveri.eng.sun.com/129.144.125.120

// "windir=c:\\\\windows"
[I:/work/bug/runtime] l:/java/jdk1.3/win32/bin/java QuoteBackslash
java.net.UnknownHostException: kaveri.eng.sun.com
        at java.net.InetAddress.getAllByName0(InetAddress.java:579)
        at java.net.InetAddress.getAllByName0(InetAddress.java:548)
        at java.net.InetAddress.getAllByName(InetAddress.java:541)
        at java.net.InetAddress.getLocalHost(InetAddress.java:731)
        at GetLocalHost.main(GetLocalHost.java:10)
Exception in thread "main"


Earlier tests seem to indicate that this inconsistency exists at least as far
back as JDK1.1.6.  This behaviour is particularly problematic since it is
impossible to distinguish 95 from 98 in Cricket.

The behaviour in NT or 98 is preferable.

iris.garcia@eng 1999-07-19

Comments
EVALUATION The Runtime.exec() has not clear spec. Since the process is a native concept, it is impossible to achieve platform independent behavior. For this specific case, I think it is OS problem. Though we can workaround them in vm, but it is better we have a clear spec before we implement that. The current behavior is to let the os handle it. ###@###.### 1999-07-22 Just because the commad syntax may vary some between platforms does not mean we shouldn't try and achieve some platform independent behavior. I agree it comes down to a spec issue, and I would like to push very strongly for a spec that says that there is no need to escape beforehand any special characters that might need to be escaped because of the idiosyncracies of the OS: such escape will be done (if necessary) by the Java veneer code. The intent should be that I should be able to write a little GUI program in which I can type an array of strings that look pretty darn similar to what I might type in a simple command at a simple shell and have the corresponding command execd. jonathan.gibbons@Eng 1999-07-22 Whatever vm does, we must have a clear spec for it. The current behavior is we try to let os handle everything. At this moment, the user of Runtime.exec() should handle the os difference and pass a decent string to exec(). In the future, we should have another exec() API that can help the situation. Anyway, I think making individual workaround without clear spec will make things worse. ###@###.### 1999-09-01
01-09-1999

WORK AROUND None. It is impossible to distinguish Windows95 from Windows98 in Cricket. ==== The system property "os.version" will be 4.10 in Win98 and 4.0 in Win95. anand.palaniswamy@Eng 1999-07-22
22-07-1999