Quantcast

remsh

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

remsh

Carlo Bertoldi-2
Hello list,
  I'm trying to connect to a remote node and execute a function.
If I do it the manual way, it works:

erl -sname foo -remsh prova@gorgonzola
1> probe_db_manager:cleanup().
true

But if I try to do it entirely from the cli it gets angry:

erl -sname foo -remsh prova@gorgonzola -run probe_db_manager cleanup

{"init terminating in
do_boot",{noproc,{gen_server,call,[{global,probe_db_manager},cleanup]}}}

probe_db_manager is a gen_server process.
I also tried this: erl -sname foo -remsh prova@gorgonzola -run global
whereis_name probe_db_manager
and it returns nothing.

Thanks,
  Carlo


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: remsh

Jon Watte
If I understand it correctly, "remsh" specifies to create an interactive shell conneted to the remote node, but a command-line argument is evaluated using the local node.
Try evaluating it as a rpc:call expression instead? You won't need a -remsh at all then, instead passing the node argument to the rpc call.

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.



On Tue, Jul 12, 2011 at 9:06 AM, Carlo Bertoldi <[hidden email]> wrote:
Hello list,
 I'm trying to connect to a remote node and execute a function.
If I do it the manual way, it works:

erl -sname foo -remsh prova@gorgonzola
1> probe_db_manager:cleanup().
true

But if I try to do it entirely from the cli it gets angry:

erl -sname foo -remsh prova@gorgonzola -run probe_db_manager cleanup

{"init terminating in do_boot",{noproc,{gen_server,call,[{global,probe_db_manager},cleanup]}}}

probe_db_manager is a gen_server process.
I also tried this: erl -sname foo -remsh prova@gorgonzola -run global whereis_name probe_db_manager
and it returns nothing.

Thanks,
 Carlo


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: remsh

Carlo Bertoldi-2
Thank you for your feedback.
That's exactly what I did eventually. :)
Cheers,
  Carlo

On 14/07/2011 03:23, Jon Watte wrote:

> If I understand it correctly, "remsh" specifies to create an interactive
> shell conneted to the remote node, but a command-line argument is
> evaluated using the local node.
> Try evaluating it as a rpc:call expression instead? You won't need a
> -remsh at all then, instead passing the node argument to the rpc call.
>
> Sincerely,
>
> jw
>
>
> --
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world.
> Nevertheless, whether we get there willingly or not, we shall soon have
> lower consumption rates, because our present rates are unsustainable.
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: remsh

Vincent de Phily
In reply to this post by Jon Watte
On Wednesday 13 July 2011 18:23:41 Jon Watte wrote:
> If I understand it correctly, "remsh" specifies to create an interactive
> shell conneted to the remote node, but a command-line argument is evaluated
> using the local node.
> Try evaluating it as a rpc:call expression instead? You won't need a -remsh
> at all then, instead passing the node argument to the rpc call.

That's how I understand it too, and it's really annoying that you can only use
remsh interactively.

rpc:call/4 is fine, but it only works one call at a time, needs to send all
the results over the wire, and becomes useless as soon as you use terms that
are tied to the VM.

I've tried all maners of techniques to send input to a remsh: -eval, -noshell,
-oldshell, -noinput, using a pipe, echoing in /proc/$PID/fd/0... The only
thing that works is a hack with X that simulates keyboard input.

Another thing that works is
erl -noinput -name foobar@127.0.0.1 \
    -eval "try {ok,S,_} = erl_scan:string(\"$YOURCODEHERE\"),                                                                                                                                
               {ok,P} = erl_parse:parse_exprs(S),                                                                                                                                    
               {value,V,_} = rpc:call('$NODE', erl_eval, exprs, [P,[]]),                                                                                                              
               io:format(\"\\e[32mok\\e[m\n~p\n\", [V])                                                                                                                              
           catch
               _:Err -> io:format(\"\\e[31merror\\e[m\n~p\n\", [Err])
           end." \
    -s erlang halt
but it isn't much more elegant.


So I've got some nontrivial code to run remotely and automatically, but for
various reasons I do not want to have a module loaded on the remote node that
does the work. Most languages with an interactive shell will happily read from
standard input instead of from the tty, but /usr/bin/erl doesn't. It has -eval
which is great, except that it doesn't work with a remote shell. Any idea ?
--
Vincent de Phily

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: remsh

Jon Watte
Why wouldn't an rpc that does an eval() of erlang "shell" code input work?
Seems easier than faking window-system-specific keycodes...

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.



On Fri, Jul 15, 2011 at 11:30 AM, Vincent de Phily <[hidden email]> wrote:
On Wednesday 13 July 2011 18:23:41 Jon Watte wrote:
> If I understand it correctly, "remsh" specifies to create an interactive
> shell conneted to the remote node, but a command-line argument is evaluated
> using the local node.
> Try evaluating it as a rpc:call expression instead? You won't need a -remsh
> at all then, instead passing the node argument to the rpc call.

That's how I understand it too, and it's really annoying that you can only use
remsh interactively.

rpc:call/4 is fine, but it only works one call at a time, needs to send all
the results over the wire, and becomes useless as soon as you use terms that
are tied to the VM.

I've tried all maners of techniques to send input to a remsh: -eval, -noshell,
-oldshell, -noinput, using a pipe, echoing in /proc/$PID/fd/0... The only
thing that works is a hack with X that simulates keyboard input.

Another thing that works is
erl -noinput -name [hidden email] \
   -eval "try {ok,S,_} = erl_scan:string(\"$YOURCODEHERE\"),
              {ok,P} = erl_parse:parse_exprs(S),
              {value,V,_} = rpc:call('$NODE', erl_eval, exprs, [P,[]]),
              io:format(\"\\e[32mok\\e[m\n~p\n\", [V])
          catch
              _:Err -> io:format(\"\\e[31merror\\e[m\n~p\n\", [Err])
          end." \
   -s erlang halt
but it isn't much more elegant.


So I've got some nontrivial code to run remotely and automatically, but for
various reasons I do not want to have a module loaded on the remote node that
does the work. Most languages with an interactive shell will happily read from
standard input instead of from the tty, but /usr/bin/erl doesn't. It has -eval
which is great, except that it doesn't work with a remote shell. Any idea ?
--
Vincent de Phily



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: remsh

Vincent de Phily
2011/7/15, Jon Watte <[hidden email]>:
> Why wouldn't an rpc that does an eval() of erlang "shell" code input work?
> Seems easier than faking window-system-specific keycodes...

I believe the code from my previous mail (requoted below) is as close
as it gets to what you suggest. Unless I've missed a public API that
is simpler than the scan/parse/eval dance I've used here, in which
case I'd love some pointers.

But I think that kind of solution is a missed opportunity for
/usr/bin/erl anyway : we've got an amazing "-remsh" feature (which, if
I understand correctly, is implemented partially at the VM level ?),
but it is hampered by the impossibility of feeding code into it. I
*can* get things done with rpc (plus eval if necessary), but that's
much more complicated than it should be.



>> Another thing that works is
>> erl -noinput -name foobar@127.0.0.1 \
>>    -eval "try {ok,S,_} = erl_scan:string(\"$YOURCODEHERE\"),
>>               {ok,P} = erl_parse:parse_exprs(S),
>>               {value,V,_} = rpc:call('$NODE', erl_eval, exprs, [P,[]]),
>>               io:format(\"\\e[32mok\\e[m\n~p\n\", [V])
>>           catch
>>               _:Err -> io:format(\"\\e[31merror\\e[m\n~p\n\", [Err])
>>           end." \
>>    -s erlang halt
>> but it isn't much more elegant.

--
Vincent de Phily
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Loading...