On Mar 29, 2007, at 3:01 AM, Brad Penoff wrote:
[description snipped]
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.
It actually is expected behavior, meaning that I wrote it this way on
purpose, but not for an obvious (or particularly good) reason. :-\
The reason for it stems all the way back to LAM/MPI. I honestly
don't remember if we inherited LAM with this behavior (put "." in
your mpirun-PATH, so to speak) or if we added that functionality
after we inherited LAM. The reason that this behavior is there (and
therefore got carried forward to Open MPI) is because even though
obeying the $PATH is technically the Right Thing to do, it seems to
violate the Law of Least Astonishment for many users.
Specifically: many users will invoke "mpirun -np 4
something_in_the_cwd" and expect it to work.
Users *know* that "." isn't in their path, but still expect the above
command to work about (I have dim recollections of getting bug
reports of people asking why that didn't work). So I think we added
that behavior with the following rationale:
1. Explicitly doing "mpirun -np 4 ./something_in_the_cwd" still works
fine.
2. Users who intentionally (or unintentionally) run "mpirun -np 4
something_in_the_cwd" will also have it work.
3. We *only* do this behavior if a relative pathname is supplied to
the executable (to include a naked filename); when absolute
executable filenames are specified, PATH searching doesn't come into
effect. So absolute executable filenames also work just as they should.
4. We put "." at the end of the $PATH, so if you're expecting a same-
named executable to be run via some earlier directory in the PATH, it
will.
So yes, it's not technically the same as running in serial at the
shell prompt. But it seemed to astonish a few less users and
therefore decreased our support load. Only a handful of people over
the years have asked the same question you have, so I think it was
the Right Thing to do it that way, even though it's somewhat counter-
intuitive. :-\
Hope that explains the rationale...
--
Jeff Squyres
Cisco Systems
