Hi folks,
looking at the code before falling asleep
Regarding the exit code handling we have two driving forces
1) determine a success/failure depending on the operating system
(DefaultExecutor.isFailure())
2) overwrite the OS-specific semantic (DefaultExecutor.isSuccess()) - I
have ap
--- sebb <[EMAIL PROTECTED]> wrote:
> On 17/04/2008, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> >
> > --- Siegfried Goeschl <[EMAIL PROTECTED]> wrote:
> >
> > > Hi sebb,
> > >
> > > thanks for your input and I'm sorry for my late
> > > response - I will look
> > > at the stuff during the we
On 17/04/2008, Matt Benson <[EMAIL PROTECTED]> wrote:
>
> --- Siegfried Goeschl <[EMAIL PROTECTED]> wrote:
>
> > Hi sebb,
> >
> > thanks for your input and I'm sorry for my late
> > response - I will look
> > at the stuff during the weekend
> >
> > Siegfried Goeschl
> >
> > sebb wrote:
>
--- Siegfried Goeschl <[EMAIL PROTECTED]> wrote:
> Hi sebb,
>
> thanks for your input and I'm sorry for my late
> response - I will look
> at the stuff during the weekend
>
> Siegfried Goeschl
>
> sebb wrote:
> > VMS testing has revealed that the
> DefaultExecutorTest class assumes
> > that 0
Hi sebb,
thanks for your input and I'm sorry for my late response - I will look
at the stuff during the weekend
Siegfried Goeschl
sebb wrote:
VMS testing has revealed that the DefaultExecutorTest class assumes
that 0 = success, and 1 = failure.
This is not the case for all OSes - VMS regard
VMS testing has revealed that the DefaultExecutorTest class assumes
that 0 = success, and 1 = failure.
This is not the case for all OSes - VMS regards odd numbers as
successful and even ones as failures.
So I think the test needs to use a more versatile means of checking statuses.
There is a met
