commanding screen from elsewhere

jedihawk · 07-15-2005, 03:00 PM

Greetings all,

I'm having trouble giving a detached screen a command from another shell. Is this possible?

Here's what I've done:

In window 1, I setup a screen like this:

Code:

$ screen -d -m -S hawktest01

This starts a bash shell in a detached screen, and it appears in the screen list:

Code:

$ screen -ls
There is a screen on:
       25704.hawktest01        (Detached)
1 Socket in /home/jedihawk/.screen.

Now, if I attach to it like this:

Code:

$ screen -r hawktest01

I get the screen session and my bash prompt and all is well. Then I hit Ctrl-A D to detach and I'm back where I was.

From window 2, I run:

Code:

$ screen -S hawktest01 -X readreg 1 hawk

This sends a command to the screen with the name 'hawktest01', which I just setup in window 1. The command tells screen to read the contents of the file 'hawk' and put it into register 1, which is just a temporary user space, like a copy buffer. The contents of the file 'hawk' is 'hawk'; I'm keeping this simple.

I follow this command with another:

Code:

$ screen -S hawktest01 -X process 1

This command puts the contents of register 1 into the keyboard buffer, as if the user had typed it.

The problem is that if the screen in window 1 is detached, the above two commands don't work--but they also don't give any indication that they didn't work.

If, however, I re-attach to the screen session in window 1:

Code:

$ screen -r hawktest01

And then I run the above two commands again from window 2:

Code:

$ screen -S hawktest01 -X readreg 1 hawk
$ screen -S hawktest01 -X process 1

The word 'hawk' appears in window 1, as it should. Basically, I'm commanding another screen session from remote (but I'm on the same machine). This procedure doesn't seem to work if the screen session in window 1 is detached.

Is it possible to send commands to a detached screen session?

-Hawk

Kahless · 07-17-2005, 01:31 AM

I dont know for sure, but if its possible, it should be documented in

man screen.

CroMagnon · 07-17-2005, 01:39 AM

From reading the screen man page, it seems to me that the process command is not working for you because it needs a display associated with the window, and a detached screen doesn't have one.

There is an alternative way to send commands to a window, and it works when detached (I've just tested it).

Code:

screen -S hawktest01 -X exec .\!. echo ls

This runs the command "ls" in the session by telling screen to run "echo ls", but redirecting the standard output to the screen window's input. The backslash is needed if you're running the command from bash, because otherwise it is expanded as a special character; if you don't use bash, you might not need it. Check out the man page details on 'exec' for more possibilities.

jedihawk · 07-18-2005, 12:26 PM

Quote:

Originally posted by CroMagnon
From reading the screen man page, it seems to me that the process command is not working for you because it needs a display associated with the window, and a detached screen doesn't have one.

Good point, hadn't thought of that. I did try the -p 0 command-line option, but had no luck with it.

Quote:

There is an alternative way to send commands to a window, and it works when detached (I've just tested it).

Code:

screen -S hawktest01 -X exec .\!. echo ls

This runs the command "ls" in the session by telling screen to run "echo ls", but redirecting the standard output to the screen window's input. The backslash is needed if you're running the command from bash, because otherwise it is expanded as a special character; if you don't use bash, you might not need it. Check out the man page details on 'exec' for more possibilities.

Thanks for the help, CroMagnon. That worked for running a subcommand while running the shell. However, my main purpose for commanding a screen session from elsewhere is so that I can run a program with an interactive macro.

I use:

Code:

screen -p 0 -X hardcopy screenshot_temp

to grab what's on screen's "screen" within the running program, and then decide what to do next.

If I use the exec command, screen will open up a subprocess and send all output to the shell, which creates a big mess on the screen because the program I want to command uses a lot of ANSI to draw the screen. Outputting all that to the shell causes a lot of "command not found" messages that look like this:

Code:

bash: 49m1049l: command not found

However, if I run my control program in virtual screen 0, and have it command virtual screen 1, then it seems to work just fine because we're running within an attached screen session. It even switches to virtual screen 1 so I can watch it work. So... I think I've got something useful going here.

Thanks again for your help on this.

-Hawk

LinuxGeek · 07-19-2005, 02:39 PM

This is quite interesting. Do you guys have any more tips on what you can do with screen. I'm basically just using the basics such as multiplexing sessions and copy and pasting and searching, etc. Any new ideas of what I can achieve would be great...

CroMagnon · 07-19-2005, 06:38 PM

The only good way I know of is to read the man page and try to use your imagination. I don't really use any of the stranger features myself, I just like to be able to check on long-running commands from different locations (and it's nice to have scrollback available across sessions).

jedihawk · 07-20-2005, 11:08 AM

Quote:

Originally posted by LinuxGeek
This is quite interesting. Do you guys have any more tips on what you can do with screen. I'm basically just using the basics such as multiplexing sessions and copy and pasting and searching, etc. Any new ideas of what I can achieve would be great...

Well, that's mostly what I use it for, but recently my boss asked me to build a script to run another program from within screen, so I had to get busy and read the documentation.

The man page is very extensive. For the more advanced functions like what I'm doing, it's good to setup two screens and practice practice practice until you understand how the functions work.