RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat
Ivan Gerasimov
ivan.gerasimov at oracle.com
Wed Feb 26 21:30:55 UTC 2014
On 24.02.2014 23:38, Martin Buchholz wrote:
> 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
>
OK. Here's another iteration.
I introduced a utility class UnixCommands, which encapsulates searching
for the command under several fixed directories.
I didn't touch /dev/null though. I think we can assume it exists in
every Unix system. Many other tests depend on it anyways.
Would you please have a chance to review the updated wevrev?
http://cr.openjdk.java.net/~igerasim/6943190/1/webrev/
Sincerely yours,
Ivan
> Doing OS-specific things like:
>
> + static final boolean isLinux =
> + System.getProperty("os.name <http://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 <mailto:ivan.gerasimov at oracle.com>> wrote:
>
> Hello!
>
> We've got one quite old report about been unable to run the test
> under Android.
> https://bugs.openjdk.java.net/browse/JDK-6943190
>
> 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:
> http://cr.openjdk.java.net/~igerasim/6943190/0/webrev/
> <http://cr.openjdk.java.net/%7Eigerasim/6943190/0/webrev/>
>
> 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,
> Ivan
>
>
>
More information about the core-libs-dev
mailing list