I feel like I'm missing something stupid obvious, but I've looked all over and can't find the answer to my question.
Suppose I have an application release that I've built with rebar and I start it a la
rel/my_app/bin/my_app start
I let it happily go about its business for a while, and then I want to attach a console to check on things, so I do
rel/my_app/bin/my_app attach
and get a shell. I muck around, and then when I'm done I want to quit the shell but leave the application running. If I do ^G q or q()., it brings down the entire application.
I've also played with starting the app with +Bi to stop it from allowing someone to accidentally close it, but then how does one even exit an attached shell at all?
I don't use rebar, I've never understood what problem it was meant to solve, but I assume when you "attach" you are doing the same thing as running to_erl. To exit in from this you type control-D (EOF).
CTRL-D should get you out and keep the app running.
Eshell V10.7 (abort with ^G)
$ Ctrl^G
$ q
here，you can quit the remote console
If it's an ordinary remote shell, hitting Ctrl-C twice ought to do the trick.
Related
When I run \dt (and other commands of psql like \l) this thing appears. What is this? Is this an editor?
Most importantly, when I click Ctrl+Z, I get thrown out of psql completely. How do I exit it without exiting psql?
I am totally new to Ubuntu, so sorry if its a dumb question. Thanks for your time on advance!
You seem to come from Windows.
The pager that gets invoked whenever a query result does not fit on your screen is something similar to Windows' more, so you exit it by typing q.
If you don't want a pager at all, set the environment variable PAGER to an empty string:
PAGER='' psql
Typing Ctrl+Z will not send an End-of-file on Linux, it will suspend the current foreground process, which continues to lurk in the background. You can rescue it from there with the command fg.
I've been working through the Erlang tutorials in Seven Languages in Seven Weeks using Erlide for eclipse and for the most part all seemed to be ok until i got to the concurrency section.
In this section, the author walks through a simple example
loop() ->
receive
"casa" ->
io:format("house~n"),
loop();
"blanca" ->
io:format("white~n"),
loop();
_ -> io:format("no comprendo~n"),
loop()
end.
When running as suggested by the book i should be able to send messages with Pid ! "someStuff". However when running this, nothing is returned and the debugger requires i kill the process before any activity resumes.
Here's an example of the console. You'll see when i send the message, nothing is returned.
Eshell V5.10.4
(ErlangDay3#Jeff-PC)1> Pid = spawn(fun translate:loop/0).
<0.202.0>
(ErlangDay3#Jeff-PC)2> Pid ! "casa".
Pid ! "hello?".
WhatJustHappened.
This all seems to run perfectly through the command line directly with Eshell (without eclipse and erlide). Could i have missed some configuration somewhere? I'm now completely stumped. I realize that maybe SO is not the best place for a question like this, however i've completely exhausted my google-fu and it doesn't appear that erlide has any forum presence.
Thanks for any and all advice.
In case it helps anything i'm running windows 7 and eclipse (STS, 3.3.0), with Erlang 5.10.4 (R16B03-1)
Thanks for the report!
This was a bug that I was hunting unsuccessfully since a while back, but now I managed to find and fix it. Please try the latest nightly build from http://download.erlide.org/update/nightly
Is it possible to force stop a .wlua file? I figured that I would have to use the Lua Command Line to do this, but I can't seem to find out how to stop them.
If it's possible, how can it be done?
Because wlua.exe doesn't open the console window (that's the purpose) and you can't send Ctrl-C, the only way to terminate such application is to use Processes window in Task Manager. Note, however, that the process name will be wlua.exe for every file opened that way.
Of course, it's meant only to be used when the application isn't responding. Your GUI application should provide a way to close it, such as close button, listening for ESC key etc.
Okay here's my problem.
I type in "rails s" and then my terminal won't let me type in any commands. So I have to start a new terminal window, which is pretty annoying.
On the other hand I can type in "rails s -d" which detaches, and then it's a pain to stop the server when I need to. (Instead of using control+c, I have to find the PID and use kill -9 PID)
I'm not a professional, so if anyone has any advice it would be much appreciated, thank you!
I don't believe there is a way to do the thing you are specifically asking for.
However, I use Iterm2 which allows me to open multiple terminal windows in one window, either by splitting my iTerm2 window or by creating multiple tabs. That way I can just make the terminals that are holding rails server and my development.log tail very small unless something interesting happens in them.
I use screen, you can also use TMUX but they are window managers in terminal and you can create multiple windows in same terminal window :)
Read up on them at WikiVS as that might help you :)
http://www.wikivs.com/wiki/Screen_vs_tmux
Screen: http://www.gnu.org/software/screen/
TMUX: http://tmux.sourceforge.net/
So you can easily switch and maintain same terminal window. You can't obviously use the EXACT same window that rails server running but it's close enough without having to do the searching for the PID.
You can type: rails s &. I'm not sure if this is what you meant.
I'm on mac osx using zsh. If I start a rails server with "rails s" I can put it in the background by hitting "ctrl-z" in my terminal (zsh).
If I open up a different terminal window then I don't see the rails server if I do "jobs". However, I can see it when I do "ps".
Is there a way I can somehow "unpause" the rails server in this new terminal window?
You can not easily move a process to a new tty. The easiest solution would be to start it in a screen session, detach screen and then resume in the new terminal.
The job is "stopped" by sending it a SIGSTOP.Your C-z doesn't send the job into the background. It "stops" it. You can then move it into the background using the bg shell builtin. However, if you send this process a SIGCONT (kill -CONT <pid>), it should bring the process back to the foreground. This can be done from a different shell.
You will not see it if you type jobs because it is a job controlled by a different shell (the other terminal window and not the one where you typed jobs). Processes however are "global" and can be seen from anywhere using the ps command (as you rightly pointed out).
Update: Looks like I spoke too soon. Apparently, the signal alone isn't enough to bring it back to the foreground. Probably something to do with the shell.