Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
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
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
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:
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.
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.
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!
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