Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

From: Brad Penoff (penoff_at_[hidden])
Date: 2007-03-29 03:01:34


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" its body. If "." (nor $HOME) isn't in your $PATH then of course

[~]$ 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

[~]$ 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.