JDK-4230399 : (process) Runtime.exec() for Solaris trips over directories in the path
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.1.7,1.2.0,1.2.2
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.6
  • CPU: generic
  • Submitted: 1999-04-16
  • Updated: 2001-10-17
  • Resolved: 2001-09-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0 beta3Fixed
Related Reports
Duplicate :  
Description
(Bugid 4202425 covers this situation, but it was closed as a result of some
 invalid reasoning from false premises, so I'm resubmitting with a counter-
 argument.)

If the PATH contains "/home/user/netscape" before
"/js/files/JDK1.2_latest/solaris/bin", and the directory
"/home/user/netscape/java" exists, then Runtime.exec("java -fullversion")
will fail whereas Runtime.exec("env java -fullversion") will succeed.

The code in src/solaris/native/java/lang/UnixProcess_md.c searches the PATH
in a nonstandard way: as soon as it finds a directory with the same name as
the target command, it aborts with an error message such as
"java: cannot execute".  Because the shells do not do this, the root cause is
highly nonobvious.

Bugid 4202425 was closed as not-a-bug.  The evaluation by hzhang@eng says
because the JLS is silent on Runtime.exec()'s semantics, this is not a bug.
On the contrary, the exec() semantics are defined by the implementation OS.
For Solaris (and other Unix variants), the correct model is execvp(3) (but
/bin/sh is good too).

I am unable to reproduce the behavior in bash or csh as described by anandp@eng
in 4202425.  Instead, csh -c uptime and bash -c uptime both run /usr/bin/uptime
even though /files/aecolley/local/bin precedes /usr/bin in my PATH and
I've mkdir'd /files/aecolley/local/bin/uptime.  Consequently, I cannot reach
Anand's conclusion that fixing the bug would be counter-intuitive to Unix
users, but must support the opposite conclusion.

I agree that the Java runtime should not search the path itself; rather, it
should use execvp (in the Solaris build) to do the dirty work.  However,
there is no execvpe function, so there is no alternative but to do the search.
The search semantics are well-defined (see Suggested Fix).

At the very least, the error message produced in fullPath() should instead
be produced in statExecutable, so that the error message contains the full
path of the failed pathname.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta3 FIXED IN: merlin-beta3 INTEGRATED IN: merlin-beta3 VERIFIED IN: merlin-beta3
2004-06-14

WORK AROUND Use only absolute paths to the command in Runtime.exec().
2004-06-11

SUGGESTED FIX Follow what /bin/sh does: skip files that (a) do not exist; (b) are not regular files; or (c) are not executable by the current user. Always report absolute pathname in errors arising from path searches. ===== (Suggested by Fred Oliver in 4202425): In the routine fullPath(), in process_md.c (1.1.7) or UNIXProcess_md.c (1.2): --- UNIXProcess_md.c Tue Jan 12 13:19:17 1999 *************** *** 121,129 **** if (ret == -1) { /* doesn't exist */ continue; } else if (ret == -2) { /* can't execute */ ! jio_snprintf(full, MAXPATHLEN, "%s: cannot execute", part); ! JNU_ThrowByName(env, "java/io/IOException", full); ! return 0; } else { return full; } --- 121,127 ---- if (ret == -1) { /* doesn't exist */ continue; } else if (ret == -2) { /* can't execute */ ! continue; /* bug 4199993 - got to keep searching. */ } else { return full; }
2004-06-11

PUBLIC COMMENTS Solaris fix was ported to Linux.
2004-06-10

EVALUATION I agree that we should skip directories. See comments for what went wrong in my evaluation of 4202425. anand.palaniswamy@Eng 1999-05-19 fred.oliver@East 2001-07-25 Currently (JDK1.4 beta) this appears to be fixed in the Solaris version We need to port Solaris fix to Linux ###@###.### 2001-09-11
1999-05-19