On 11/19/07 8:19 AM, "Jeff Squyres" wrote:
> On Nov 19, 2007, at 10:15 AM, Ralph H Castain wrote:
>
>> Hmmm...okay, I get the message: if it is going to be fixed, then I
>> have to
>> fix it on my end. ;-) Which means it ain't happening anytime soon,
>> so Tim P
>> is the one left in the lurc
On Nov 19, 2007, at 10:15 AM, Ralph H Castain wrote:
Hmmm...okay, I get the message: if it is going to be fixed, then I
have to
fix it on my end. ;-) Which means it ain't happening anytime soon,
so Tim P
is the one left in the lurch.
Sorry Tim! Perhaps you can come up with a compromise that
Hmmm...okay, I get the message: if it is going to be fixed, then I have to
fix it on my end. ;-) Which means it ain't happening anytime soon, so Tim P
is the one left in the lurch.
Sorry Tim! Perhaps you can come up with a compromise that re-enables what
you want to do.
Ralph
On 11/19/07 8:11
On Nov 19, 2007, at 10:01 AM, Ralph H Castain wrote:
Unfortunately, it -is- a significant problem when passing the params
on to
the orteds, as Tim has eloquently pointed out in his original
posting. I
guess I don't see why it would be a significant problem to just have
opal_cmd_line_parse do
Unfortunately, it -is- a significant problem when passing the params on to
the orteds, as Tim has eloquently pointed out in his original posting. I
guess I don't see why it would be a significant problem to just have
opal_cmd_line_parse do the "right thing" - if a string param is quoted, then
just
I guess I don't see why this is an opal_cmd_line_parse() problem.
If you invoke executables through system(), then a shell is used and
quoting is necessary to preserve the individual string tokens (i.e.,
"my beloved string" would be passed to the application as one argv
token, without the q
My, you are joining late! ;-)
The problem is with MCA params that take string arguments. If we pass the
following:
-mca foo "my beloved string"
on the command line of an orted, we get a value for foo that includes the
quote marks. I verified this rather painfully when attempting to pass a
comman
Sorry -- I'm just joining this conversation late: what's the problem
with opal_cmd_line_parse?
It should obey all quoting from shells, etc. I.e., it shouldn't care
about tokens with special characters (to include spaces) because the
shell divides all of that stuff up -- it just gets a char
I'm not sure it is really necessary - the problem is solely within
opal_cmd_line_parse and (if someone can parse that code ;-)) is truly simple
to fix. The overly long cmd line issue is due to a bug that Josh was going
to look at (may already have done so while I was out of touch).
Ralph
On 11/
Should there be another option for passing MCA parameters between
processes, such as via stdin (or any file descriptor)? I.e., during
the command line parsing to check for command line MCA params, perhaps
a new argument could be introduced: -mcauri , where could
be a few different forms:
Might I suggest:
https://svn.open-mpi.org/trac/ompi/ticket/1073
It deals with some of these issues and explains the boundaries of the
problem. As for what a string param can contain, I have no opinion. I only
note that it must handle special characters such as ';', '/', etc. that are
typically fo
The alias option you presented does not work. I think we do some weird
things to find the absolute path for ssh, instead of just issuing the
command.
I would spend some time fixing this, but I don't want to do it wrong. We
could quote all the param values, and change the parser to remove the
What changed is that we never passed mca params to the orted before - they
always went to the app, but it's the orted that has the issue. There is a
bug ticket thread on this subject - I forget the number immediately.
Basically, the problem was that we cannot generally pass the local
environment t
I'm curious what changed to make this a problem. How were we passing mca param
from the base to the app before, and why did it change?
I think that options 1 & 2 below are no good, since we, in general, allow
string mca params to have spaces (as far as I understand it). So a more
general approa
Sorry for delay - wasn't ignoring the issue.
There are several fixes to this problem - ranging in order from least to
most work:
1. just alias "ssh" to be "ssh -Y" and run without setting the mca param. It
won't affect anything on the backend because the daemon/procs don't use ssh.
2. include "p
Hi,
Commit 16364 broke things when using multiword mca param values. For
instance:
mpirun --debug-daemons -mca orte_debug 1 -mca pls rsh -mca pls_rsh_agent
"ssh -Y" xterm
Will crash and burn, because the value "ssh -Y" is being stored into the
argv orted_cmd_line in orterun.c:1506. This is
16 matches
Mail list logo
