[Horus]

Hello,

I'm wondering why some (all?) pyFoam tools do not return a non-zero return code if the openfoam tool fails.

For example:

pyFoamRunner.py --autosense-parallel potentialFoam -noFunctionObjects

fails because there is some dictionary entry missing, the return code is 0.

mpirun -n 2 potentialFoam -noFunctionObjects

fails too, but with a return code of 1.

Same for pyFoamRunner.py.

Returning non-zero exit code to indicate an error makes it much easier for scripts to use pyFoam.

Any reason for this design decision or just not implemented yet?

Regards,

Florian

[gschaider]

Originally Posted by Horus

Hello,

I'm wondering why some (all?) pyFoam tools do not return a non-zero return code if the openfoam tool fails.

For example:

pyFoamRunner.py --autosense-parallel potentialFoam -noFunctionObjects

fails because there is some dictionary entry missing, the return code is 0.

mpirun -n 2 potentialFoam -noFunctionObjects

fails too, but with a return code of 1.

Same for pyFoamRunner.py.

Returning non-zero exit code to indicate an error makes it much easier for scripts to use pyFoam.

Any reason for this design decision or just not implemented yet?

Regards,

Florian

Reasons are:

- I didn't need it yet (I don't check return codes in shell-scripts. If that is necessary I use Python)
- there was no feature-request on the Mantis yet

So this is NO design decision

[Horus]

Ok, the bugtracker is offline at the moment, I will file a request later and will also have a look at the code and see if I can produce a patch.

[gschaider]

Originally Posted by Horus

Ok, the bugtracker is offline at the moment, I will file a request later and

OK. I admit it. I hacked them so that this request would not come through

Originally Posted by Horus

will also have a look at the code and see if I can produce a patch.

Oh. Great. Under these circumstances I will allow sourceforge to continue with its operations