RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat

[Ivan Gerasimov]

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.
>> Both tests in the case of a failure could interfere with other tests 
>> unless they run in the othervm mode.
>> That's why I thought it's better to add the flag.
> If a test is badly behaved and is leaving streams open then I would 
> agree with othervm. However these are old issues (right?) and should 
> not be happening now. Also if a test tickles a bug that causes the VM 
> to crash then jtreg will spin up a new VM for the next test. So if 
> it's possible to avoid othervm then we should (and from what I can 
> tell then these tests have been well behaved when running without 
> othervm before).
>
Yes, got it.
I will remove othervm mode.

Once I was suggested to add the othervm mode to the test which was to 
detect a memory leak (in the case of a poor behavior).
So I was under wrong impression that we need to use this mode even when 
normal run of a test doesn't influence any other.

Omitting othervm for the tests that do not interfere with others during 
normal runs does make sense, and I will follow this rule from now on.

>>
>> IMO ideally, there should be a configurable part of the harness, 
>> where all the shell commands are set up.
>> So that they could be accessed by both Java and shell-based regtests.
> test/lib/testlibrary is the place for test-suite wide infrastructure. 
> I don't know if there are tests beyond the Process area that needs to 
> do the same kind of thing.
>
I meant something that can be configured by a user of the harness.
It's beyond the scope of this bug, of course.

Sincerely yours,
Ivan