I am using rebar for release build of erlang application, when I use start option to start the application it is running fine in background and It returns me the command prompt. I don't want to see all the background output, so I did not run using console option. But If I need any time what is going in background, to check the console due to any error, how do I get that running application's console?
I guess that you have made a release using Rebar and that you have started the node with the generated start script.
So the best way would be to use the start option 'attach':
./bin/mynode attach
It will connect to the shell through pipes so you will be in the actual node that are running so be careful with using Ctrl-c. (add the option "+Bi" to your vm.args file to restrict that..)
You can connect a remote shell to the node, provided it's been set up for distribution. Use the following command:
erl -sname rem -remsh node#host -setcookie the_cookie -hidden
Ctrl-G to enter JCL mode, then 'j' to list, then 'c' followed by a number to connect to the chosen job. See the eshell docs, specifically the JCL section.
Oh, or if by 'command prompt' you mean an OS shell rather than an Erlang shell, IIRC you need to start an Erlang node that is appropriately -name'd or -sname'd (whichever the node you want to connect to uses), then connect to that node ('r' in JCL mode), then connect to the job.
Related
Hello i was trying to issue some distributed erlang commands such as erl -sname/erl -name and i do not get a response.
If i put . at the end it says syntax error.
If i don't it won't return anything and it will treat it like an unfinished command.
I thought this is only for these commands but it seems there are others that will not do anything like
erl -man <module_name>.
Do i need to set something up to be able to issue erl commands.
P.S OS is Windows 10.
The erl command (with or without -sname) is simply how you run Erlang from a console window like cmd or powershell. On Windows, to get a fully working Erlang shell with command line editing etc, you need to use the special werl executable instead of erl - this is due to how Windows consoles work. Try opening a cmd or powershell windows and see how it works.
If you open the properties of the icon you have used for starting Erlang, you will see that the command it is running is werl (from the Start menu you have to use "more -> open file path" to find the actual icon first). You can edit this and add options like -sname yournodename to the command, or you can create a copy of the icon (e.g. to your desktop) and give it a more suitable name, like "My Erlang node", and then edit its options.
How do I show the absolute path that my Erlang OTP application is loading sys.config from? I.e., if get_all_env (http://erlang.org/doc/apps/kernel/application.html#get_all_env-0) shows unexpected results, how do I see what file is being loaded to debug?
I did this once, so I know it is possible, but sadly I cannot find that code =(
You can use init:get_plain_arguments/0 to get the full list of VM arguments:
(node#localhost)13> init:get_plain_arguments().
["/usr/local/bin/rebar3","shell","--apps","some_app",
"--config","priv/sys.config","--sname","node1#localhost"]
That certainly works if you have started the node manually on CLI. For reference, the output above corresponds to my start script using rebar3:
rebar3 shell --apps some_app --config priv/sys.config --sname node1#localhost
I use run_erl to start an erlang application, just like this
run_erl -daemon /tmp/erl_pipe /tmp/erl_log "erl -name 1#127.0.0.1 -setcookie 123456"
Then I Attach to erlang shell like this
to_erl /tmp/erl_pipe
And the question is, I used to quit erlang shell with 'ctrl + c', in this situation, 'ctrl+c' will quit the main node, I have seen my lead to ban this command by modify erlang/OTP source code, how to do that?
Start Erlang as erl +Bi. Note that you'll have to use init:stop() (shortcut q() in the shell) or halt() to stop the node if signals are ignored. Also, the Ctrl-G menu will not have the q option if you use this flag.
It is also possible to use +Bc, which makes Ctrl-C abort the current shell command instead of stopping the whole node. In this case, you can still use q from the Ctrl-G menu.
See http://erlang.org/doc/man/erl.html#emu_flags for the full documentation on runtime system flags.
I've created a simple erlang release using rebar, following this tutorial: http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-upgrades
I can install and start the dummynode by going to the dummynode/bin folder and running:
dummynode install
dummynode start
In the vm.args file, I've set the node name to dummynode#192.168.1.129
When I start another node with:
erl -name cole#192.168.1.129 -setcookie dummynode
I can then launch the erlang observer. In the "Nodes" menu, I see that the dummynode node is listed, but when I try to connect, observer crashes.
I can't make heads or tails of the crash dump file, but it seems like erlang is complaining about distribution not being enabled.
I cannot connect the nodes with net_adm:ping/1 and can't figure out why observer was able to at least see the detached dummynode node.
Can anyone explain how I can connect to the dummynode node?
UPDATE: I've confirmed that the cookies are the same on both nodes. Also, AFAICT rebar is packaging observer and all of it's dependencies into the release.
If you cannot connect with net_adm:ping/1 check that both nodes have the same cookie (erlang:get_cookie/0).
The 2 nodes must have the same cookie to form a distributed system, but observer can show you at least all the nodes that are present on your machine, even if they have not the samme cookie.
Observer needs some modules installed on remote node to run. It crashes silently if they are not presented there. I don't remember which ones it was so you have to experiment so add some application requirements to your target distribution.
Mystery solved! It was neither a cookie nor dependency issue. The generated vm.args file has a line:
-name dummynode#127.0.0.1
Which you'd think would mean that if I change the node name to something like
-name mynode#mydomain.com
then rebar would start the runtime with the flag:
erl -name mynode#mydomain.com
This is not the case. It turns out that rebar always invokes the runtime (at least on windows) with the -sname flag, even if you adjust the node name. If you want to distribute your cluster across physical machines (using long names with the -name flag) you need to edit the generated bin\dummynode.cmd file, and change all of the -sname flags to -name.
I've filed an issue with the rebar team, but I don't know if they consider this to be a bug or not.
I'm trying to modify a legacy Delphi 5 app so that it can be launched either from it's icon/via Explorer, or from the console (command-line). When it gets launched from the console, I want the program to detach itself from the console process, so that the console can continue to execute other instructions without waiting for my program to terminate.
I want to use it in a 'batch' file, such that I might have;
#echo off
rem step 1 - do some stuff here
rem
rem step 2 - launch my app
c:\myfolder\myapp
rem
rem step 3 - do some more stuff here
and that the console process moves on to step 3 straight after launching my app in step 2.
I'm sure I've done this before, many years ago, but I'm puzzled as to what exactly I did. I don't want to write a tiny console app 'launcher' for my main Windows app - I'm 95% sure that there was a way of doing this within a 'normal' Delphi GUI app.
I guess I could use vbscript or powershell or something to 'execute' my program with some kind of 'nowait' parameter but the client is familiar with batch files and I don't really want to upset the applecart by suggesting he change his scripts or install additional stuff - I'm making changes to the executable anyway and it would be great to tick this box for him too.
Anyone? :-)
I think the START command is the one you're looking for. It starts a process separately to the console and it's part of cmd.exe so no extra software required.
But I was of the opinion that GUI apps did this anyway. Maybe Delphi is different to MSVC.
Open up a console and type "start /?".
As itowlson states in the comments, GUI application do generally detach themselves. It's the actual cmd.exe shell doing trickery in that it waits for it to finish if it's running from a cmd file.
So "notepad" from the prompt will start it in the background but "notepad" within a cmd file will wait. Within the cmd file, you need to use:
start notepad.exe
or whatever your application is called (not notepad, presumably).
try: start "" c:\myfolder\myapp (with the empty quotes)
I think Microsoft has been solve this problem in Windows Power Shell.
In command prompt, even if you use "start ", you cant detach your process really from cmd. If you close the cmd, you will die, suddenly. But In windows Power Shell, you can detach your program or command from Power Shell as default.
So, if you prefer to use Windows Power Shell instead of Command Prompt, just do this:
PS: X:\> <your command>
Here's one way that I've found. It works quite cleanly and doesn't leave any extra cmd windows around (the recommendation to use start c:\myfolder\myapp does not work:
cmd /c dir && c:\myfolder\myapp
To quote the CMD help:
/C Carries out the command specified by string and then terminates
Note that multiple commands separated by the command separator '&&'
are accepted for string if surrounded by quotes.
Apparently it notices that the dir command terminates and exits, even though your app was launched on the same command. Chalk it up to one of Windows vagaries.
u should use the cd command example
cd/
cd myfolder
start myapp
exit