Thank you Alan!
This looks okay although I would prefer for a number of these tests to
fail if the command is not found (otherwise it is will just hide issues).
Now I've got two suggestions that somehow contradict each other.
Martin suggested to check for particular OS only as a last resort,
On 20/03/2014 07:25, Ivan Gerasimov wrote:
Now I've got two suggestions that somehow contradict each other.
Martin suggested to check for particular OS only as a last resort, but
without knowing that we run under Unix, we cannot treat a command
absence as an error.
It's always hard to get
Thank you Alan!
I think we can assume that none of the tests which need UnixCommands
are for Windows, so I added explicit checking for that.
Having made sure the OS is a Unix (i.e. not Windows), the absence of
a required command now causes an exception to be thrown.
Would you please take a
Thanks Alan!
These two tests used the commands run from non very common location
(/usr/bin/ instead of /bin/), so I suspect they have been rarely run.
As it follows from the summaries, one of them ensures the VM doesn't
crash; the other checks, whether the input/output streams are left open.
Here's the (hopefully final) polished webrev: removed 'othervm' and
replaced stderr with stdout in reporting of the wrong OS.
Would you please take a look?
http://cr.openjdk.java.net/~igerasim/6943190/4/webrev/
Sincerely yours,
Ivan
Thanks Martin!
On 19.03.2014 20:23, Martin Buchholz wrote:
I expected to see System.out used instead (not that it matters much).
I would write:
System.out.println('true' command not found; skipping test);
Two cases are mixed here:
- normal run (OS does not have this command),
- erroneous
On 19/03/2014 17:34, Ivan Gerasimov wrote:
Here's the (final?) webrev:
http://cr.openjdk.java.net/~igerasim/6943190/5/webrev/
This looks okay although I would prefer for a number of these tests to
fail if the command is not found (otherwise it is will just hide
issues). We can create another
On 16/03/2014 16:52, Ivan Gerasimov wrote:
Would you please take a look at the updated webrev with your
suggestions incorporated:
http://cr.openjdk.java.net/~igerasim/6943190/3/webrev/
Ivan - I see that a number of the tests have been changed to /othervm
and I'm wondering what the reason
Thank you Alan!
On 17.03.2014 11:50, Alan Bateman wrote:
On 16/03/2014 16:52, Ivan Gerasimov wrote:
Would you please take a look at the updated webrev with your
suggestions incorporated:
http://cr.openjdk.java.net/~igerasim/6943190/3/webrev/
Ivan - I see that a number of the tests have
On 17/03/2014 09:06, Ivan Gerasimov wrote:
Thank you Alan!
These two tests used the commands run from non very common location
(/usr/bin/ instead of /bin/), so I suspect they have been rarely run.
As it follows from the summaries, one of them ensures the VM doesn't
crash; the other checks,
Thank you Martin, for your comments!
On 16.03.2014 4:41, Martin Buchholz wrote:
Thanks for trying to make these tests more robust.
33 private static final String[] paths = {/bin, /usr/bin,
34 /usr/local/bin, /system/bin, /sbin, /usr/bin/sbin,
35
Hello!
This is a friendly reminder.
Can someone with the Reviewer status please help review this?
In short: we have a few java tests that run shell commands.
In some tests the path to the command is omitted, in other tests an
absolute path is given.
In the third group of tests, the *other*
Thank you Roger for looking at this.
On 27.02.2014 2:19, roger riggs wrote:
Hi Ivan,
A few comments on UnixCommands:
- The trailing _ on the method names looks very odd, they could all
use some suffix Pgm X, etc.
I replaced true_() and false_() with explicit calls to findCommand().
-
Hi Ivan,
On 2/27/2014 4:34 AM, Ivan Gerasimov wrote:
- I'm not sure the specific command methods do you any good
(over a method with a string argument). since they immediately
revert to the string command name.
They are shorter :-)
yes, but it creates a level of indirection that someone
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
Hi Ivan,
A few comments on UnixCommands:
- The trailing _ on the method names looks very odd, they could all
use some suffix Pgm X, etc.
- I'm not sure the specific command methods do you any good
(over a method with a string argument). since they immediately
revert to the string
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
17 matches
Mail list logo
