hey,
I just had a question (and potential bug) about the expected behavior in
mpirun... I saw it in 1.1.5 and just saw that it still occurs in 1.2.
I'll illustrate with a (seemingly) silly example.
Say in your $HOME you have a sh script named testecho that just has
echo "Saying hi"
...as its body. If "." (nor $HOME) isn't in your $PATH then of course
typing...
[~]$ testecho
-bash: testecho: command not found
...returns an error.
Now say my $HOME is mounted across two machines and these two machines are
in a hostfile named "hostfile.openmpi". Even if "." isn't in the PATH on
neither machine (nor $HOME), running mpirun seems to place "." in the
PATH:
[~]$ mpirun --hostfile ~/hostfile.openmpi -np 2 testecho
Saying hi
Saying hi
The funny thing is the following returns the error that it's not found:
[~]$ mpirun --hostfile ~/hostfile.openmpi -np 2 which testecho
which: no testecho in <snip> my PATH without "." in it </snip>
which: no testecho in <snip> my PATH without "." in it </snip>
I know this seems pedantic but I just wanted whether or not these should
differ like this or if this is expected behavior, and thought I'd point it
out in case it was not.
One could say this would never happen but I can imagine a time and place
where it might affect something... who knows?
In a our test setup, we noticed that MPICH2 wasn't running our tests and
Open MPI was and it ended up being because of this issue (where Open MPI
was putting "." into the PATH (or we forgot to put "." into the PATH :-))...
... but who knows, maybe your setup deliberately didn't have "." in it,
and you WANTED an error message if some particular program was in "." but
no where else in the PATH...
What should be the expected behavior? My vague guess is that the $PATH
should be followed strictly (as "which" does) and I should be forced
to run with "./testecho", if I really want this great program to run...
but I could be convinced otherwise.
brad
