RFR  TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat
martinrb at google.com
Mon Feb 24 19:38:22 UTC 2014
Thanks for working on these ancient Process tests.
I would prefer to see them using "feature tests".
You wanna do "cat /dev/zero"? Then look for cat in /bin and /usr/bin and
check for /dev/zero as well, e.g. using File.isExecutable
Doing OS-specific things like:
+ static final boolean isLinux =
+ System.getProperty("os.name", "unknown").startsWith("Linux");
should be a last resort.
On Mon, Feb 24, 2014 at 9:26 AM, Ivan Gerasimov
<ivan.gerasimov at oracle.com>wrote:
> We've got one quite old report about been unable to run the test under
> That was due to hard-coded path to the cat utility as /bin/cat.
> When investigating, I found two other tests under the same directory that
> use /usr/bin/cat and /usr/bin/echo.
> These two test seem to (almost) never run because of the unusual path.
> Here's the first version of the webrev, with the fix to only three tests
> mentioned above:
> java/lang/Runtime/exec/ directory has also got several other tests, which
> run shell commands.
> Some of them have absolute path and some of them don't.
> So I have a general question: Why would we ever need the absolute path for
> the commands?
> Why wouldn't we rely on the PATH env variable?
> Sincerely yours,
More information about the core-libs-dev