How can I script GNU Screen to start with a program running inside of it so that it does not exit the session when the program completes?
I want to run an interactive program as a daemon, if I manually start screen and then launch this program inside of it everything works just as I want. If the program exits or crashes the screen session remains and I can go look at it to see what just happened. However, if I start the program with a simple screen launch then it does run inside of screen but when the program exits the screen session ends and any output from the program is lost.
So screen –dmS serverName serverApplication does not work for my scenario. I did think about making a script which launches the program I want to run & then sleeps forever, I could then launch the script at the same time as screen and should get the effect I am after but it seems rather an untidy way to do things and I am sure there must be something more elegant.
I have read quite a few screen tutorials and trawled through the man page but nothing leaps out at me as the right way to do this. I did try –X but that is for screen commands, not for running commands inside the screen session... Any suggestions will be very much appreciated; I am even happy to use something other than GNU Screen if there is a better tool for use in scripting but please give me an example where possible.
(Side note: The two things I will be running with this are a minecraft_server and a mythtv_backend. My plan was to launch these from a chron job at boot via some ruby/bash script)
First, you'll want to start a daemon screen session just running your default shell:
$ screen -dmS "serverName"
Then, send your command to that shell using screen's stuff in combination with -X:
$ screen -S "serverName" -p 0 -X stuff "serverApplication$(printf \\r)"
The -p is important for telling screen into which window within that session to stuff the command. In this case, it's the only available window, 0, but if you don't specify that, for some odd reason your command will go nowhere. The $(printf \\r) sends a 'Return' keystroke. A regular \n might work in its place, but I've read that's shell-dependent. The newline character does not work in bash; I can vouch for that.
Here's another cool trick. If you want to then make another screen window within that session, you can:
$ screen -S "serverName" -X screen
Now you can send commands to that one using the same syntax as above, but with -p 1. Lots of fun.
Related
I am sorry if the question doesn't make sense, I didn't really know how to phrase it properly.
What I am trying to achieve is similar to how it works in the command prompt when running a python file. When I run a python file from the command prompt, the command prompt window will jump to the last outputted line during the running of the program, so what is currently being outputted is always visible. However in my current VS Code set up, the output window will not jump to the last line as it is printed, and I have to scroll through the output window to see what is happening with the program.
I am currently using the latest version of VS Code and using the code-runner extension as well. Please let me know if what I am asking does not really make sense.
Thanks
As far as I understand your question, I would like to answer it.
To Auto-Scroll to the last output, you can just click on the Lock Icon near the Clear Console icon.
I have a couple of Rainmeter skins on top of my taskbar that act as a cooler clock, and in order to keep the skins above the taskbar, I have the following code:
[Rainmeter]
Update=500
OnUpdateAction=!ZPos #ZAxis#
[Variables]
ZAxis=1
So that keeps the skins above the taskbar, but it also keeps it above things like youtube running fullscreen. I got an AutoHotKey script that will run a program when a window becomes fullscreen and when it closes fullscreen, so I told it to launch "%PathToRainmerer%\Rainmeter.exe" !SetVariable "ZAxis" "-1" Skin.ini and "1" on the un-fullscreen, but nothing happened.
I checked everything to make sure the AHK script was working, and I even tried to run Rainmeter.exe with the parameters using a shortcut, but nothing worked. I also set up a Meter with Text=#ZAxis# and it stayed at one. I'm guessing the issue is with the syntax, but I can't find proper documentation (probably because I'm so bad at researching). I can provide more details on polite request.
Please remember that kind and respectful comments are greatly appreciated.
Try "\pathtorainmeter\rainmeter.exe" !activateconfig "mainskin folder\skin subfolder" "skin.ini"
Worked for me
I have the following problem: I want to run a really cumbersome calculation on a server via Putty in Matlab. Now I do not want to keep my notebook the whole time connected to this server, which is why I am searching for a solution to this problem. I know that screen in general works but I am not sure whether this could help me here too. The problem is the following: Each time I start this Matlab program I have no longer control over the terminal, since the Matlab program is still running. Therefore I am always forced to abort the process, which is what I do not want to happen. Is there anything that could help me.
What I need this:
1.)Start Matlab Application on server
2.)Disconnect from Server
3.)Connect to Server
4.)Have access to Matlab again
I would highly appreciate it, if somebody could give me a reference to some commands that might be helpful in this situation.
As #Peter said, screen is one good solution. A brief tutorial:
Connect to server
screen -S SectionName
matlab -nosplash -nodesktop or -nodisplay or -nojvm depending if you have allowed X11 forwarding on putty (you can check this by simply open a figure and check if you can see it with -nodesktop option)
Ctrl+a d to detach
Log out
Reconnect to server
If you are using X11 forwarding, you may need to update your display on the screen, so: echo $DISPLAY, copy its result
screen -rd SectionName
If you are using X11 forward, update display on screen export DISPLAY="value echoed outside screen" (I think the opposite also works, you set the log display into the screen display)
Finish Screen
Exit matlab and type exit
List open screens
screen -ls
Terminate unresponsive screen
Ctrl+a Ctrl+k and answer y
Navigate through screen screen:
Ctrl+esc and then use arrows or: ctrl+u to go half screen up and ctrl+d to half screen down
Exit broken connection screen
~ .
Note: You can have more than one screen section running, or you can open multiple screen windows by using Ctrl+a Ctrl+c
Note2: screen command may be very addicting, use it with cautious. Don't forget to read its man page.
I have a rather long perltk code in my hand and I would like to run the simulation in a batch mode (without using the GUI). e.g. I would like to run it with script like "myprog.pl -b" in stead of setting all the parameters in the GUI and click buttons.
My current method is using a separated XML file for config and the function "after" which means the GUI will pop-out and start the simulation then exit after sometime. It is now working, but I have a question: is there a better way solve this problem? Is that possible to have the GUI shown in the background (so we wont see it) in stead of pop-out?
Change the program so it is accessible from both a graphical and command-line interface. Factor out its real functionality into subroutines.
Run the program in an xvfb so that no window is shown on the main display.
Configure the window manager to always start instances of this program minimised and/or with a 0x0 size.
I would like to attach screen or tmux inside emacs, in shell mode. I often find myself running emacs with inferior processes inside screen on remote servers; it would be nice if I could shift the workflow to local emacs + TRAMP; ability to reattach persistent sessions is a must, however. (Such workflow is particularly useful for analysis in R [1])
Shell-mode is rather desirable because I keep encountering miscellaneous glitches and even crashes when using the combination of M-x term or M-x ansi-term + screen + R. However, I can't seem to get rid of ansi colored rendered as escape codes in screen when run under M-x shell. When I use ansi-color-for-comint-mode-on, they are fine -- but as soon as screen comes on, it becomes a horrible mess.
Has anyone figured out the set of conditions for proper interpretation of ansi color with shell + screen or tmux? What about getting rid of color altogether?.. Are there any other alternatives in terms of running persistent remote processes and attaching them to local emacs?..
[1] http://blog.nguyenvq.com/2010/07/11/using-r-ess-remote-with-screen-in-emacs/
As far as I can tell, Screen requires features of your terminal that Emacs' shell mode simply does not and cannot provide, simply because it is not a traditional character terminal like VT100. So the issue is not about getting rid of or trying to interpret color codes -- there are more terminal capabilities that Screen requires to function correctly.
By default Screen does not even start in Emacs' shell mode, as far as I can tell (it errors out saying it needs clear screen capability). Some posts around the web seem to suggest setting TERM=xterm to work around this, but it is just fooling Screen into thinking the terminal has the capabilities of XTerm, which it doesn't have.
The term and ansi-term modes of Emacs would provide the terminal capabilities required by Screen, but unfortunately you seem to have had troubles with those modes.
What I would suggest instead would be to have a look at the "emacsclient -t" command (part of Emacs), which allows you to open a local frame connected to an existing Emacs instance in a similar way as Screen allows you to reconnect to a previously created Screen instance. That way you could perhaps configure a emacsclient on you local computer to reconnect over TCP to a persistent remote Emacs instance.
I don't use screen, but maybe you can fix this from your .bashrc. I've got a bunch of conditional code in there, turning color on for xterm windows, but leaving it off for other terminals that don't support it. M-x shell sets the TERM variable to dumb, so you can test for that and set the color accordingly.
case "$TERM" in
dumb)
## non-color settings here
;;
xterm)
## color settings here
;;
*)
## default (maybe you want non-color here?)
;;
esac