LinuxQuestions.org - How to send a command to a screen session?

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - How to send a command to a screen session? (https://www.linuxquestions.org/questions/linux-software-2/how-to-send-a-command-to-a-screen-session-625015/)

How to send a command to a screen session?

I am running screen on a debian machine. To start a program with screen I run "screen -A -m -d -S sessionname command".

To send a command to a detached screen I use "screen -S sessionname -X stuff command".

However, this command only works if I have run "screen -x sessionname" first. I am making a c++ script to interact with a screen session, but it is a problem that I have to run "screen -x sessionname" first. Does anyone have a solution for my problem? :)

Yes, that is a known problem/bug. Several work-arounds have been reported on the screen-users maiing list. I have no idea whether it will ever be fixed.
--- rod.

Thx for the answer. I tried to make a system() call to a screen -x sessionname redirecting the output to /dev/null, but it didn't work. I found out that I could send the screen -x sessionname command to another (temporarily) screen session, but that didn't work neither (see below). I think it didn't happen fast enough, because if I run the script twice it will successfully send the command to the session "sessionname". Does anybody have a workaround that actually works?

Btw sorry for my bad english :D

My "workaround" that didn't work....

system ("screen -A -m -d -S temp screen -x sessionname");
system ("screen -S sessionname -X stuff 'command'");

Why do you need to send commands to a screen session that has never been in an attached state? If the answer is that it must be started at boot time, when there are no consoles to host your screen session, then perhaps my work-around can be of some use.
I start screen in an xterm that is hosted in an X virtual framebuffer, using xvfb. This allows me to start the screen session in an attached mode (in fact, it never has to become detached), allowing me to send commands to it arbitrarily. I can attach to it at any time from another 'real' xterm or from any other type of console. In the application it is used in at my site, it runs in multi-user mode, so others can also attach to the session. I launch this whole mess from /etc/rc.local
--- rod.

my problem might be similar. I am creating (or rather was until i saw this problem) a webpage for me which i can control my server. I normally go into the server via ssh and i do everything right there BUT i will be sharing my access control with several friends that are helping me out on the server. Some of the things i do in ssh involve the screen sessions like closing screens, reopening screens, sending messages to screens, etc..

What i want to do is this:

1. From my PC, in the homepage, execute an option that closes the screen and sends a message before closing. Something like:

ssh cyrex@server.com 'screen -S world -X "Closing in about 5 minutes"'

The problem is that when sending the messange to world it does not work. It does not get recieved. Any thoughts on this.

I think this is at least a little closer:

Code:

ssh cyrex@server.com 'screen -S world/ -X stuff "Closing in about 5 minutes"'

This will work if cyrex is the owner of the screen session, or if screen is running in multi-user mode. You probably also want to close off the stuffed message with a newline.

Code:

ssh syrex@server.com 'screen -S world/ -X stuff "Any message you want"`echo -ne '\015'`

--- rod.

I have found a way to make it work with the help of previous messages:

Code:

screen -A -m -d -S tempsrvname screen -x srvname;

sleep 1;

screen -S srvname -X stuff \"stop\"`echo -ne '\015'`"

I just use the solution of ThaHabbis with a delay (sleep 1) to enable the creation of the temporary screen (you may make a proper script witch detect if the temp screen is correctly created before or increase the delay if you have high load on server) and the echo of a newline to validate command to the screen prompt.

I am new here, impressive from the suggestions given by the guests.

This works for me:

screen -S <session-name> -p 0 -X stuff command

The key there is the -p 0 part. It selectes the window in which to write the command. If you don't specify it, it doesn't work unless you have already connected to the screen session.

Based on all the input from everyone... below is the final command that works...

First start a screen session... can even be a nohup process so that it persists even after you log out (leave out the & at the end if you do not want that)

Code:

screen -dmLS panel /root/shellscript_with_prompt.sh &

To send commands to the screen 2 things were missing from all the posts, which puzzled together you end up with the following. -p 0 is important and required, finally the 'hit enter' for command to execute is the echo part. Make sure you get your backticks, single and double quotes right. Note: If you started the screen session with user X, you must issue the screen -X stuff commands as user X, otherwise you can put multiuser off in your config file, or add/remote users. See the man screen for details.

Code:

screen -S panel -p 0 -X stuff "yourCommand`echo -ne '\015'`"

If you want a custom config file, I recommend the following ... place it in .screenrc (or add param 'screen -c /root/.yourrc') This is useful to control the log, buffer flush times, etc. The default flush is 10 seconds and a bit too long for my tastes, especially when you are catting your log file, looking for a result that will not come, only to find the flush time was 10 secs!

Code:

log on

logfile /tmp/whatever

logfile flush 3

While you are at it man screen to get all the nifty configs you can put in your config file. There are A LOT of them. A final note: You seem to still need the -L parameter to turn logging on, even though you have log on in your config file.

You can do some pretty cool things with AJAX, phplibsec and a browser to control a linux Server this way. Like compiling code, entering at halt points in the script, etc, all reading the output of screen from your log file, which you AJAX to... cheers