I writing a python app that runs some commands on a gnu screen without joining the screen and seeing the hardcopy buffer. In particular, I am running:
screen -dmS test
screen -S test -p 0 -X stuff "ls$(printf \\r)"
screen -S test -X hardcopy screenOutput.txt
when I look at screenOutput.txt, I see nothing.
However, if I join the screen, and then run hardcopy,
screen -dmS test
screen -S test -p 0 -X stuff "ls$(printf \\r)"
screen -r test
(quit the screen with c-A c-D)
screen -S test -X hardcopy screenOutput.txt
Then I see the output in screenOutput.txt.
Is there a way to get hardcopy to write to the file, without joining the screen?
See linux - Send command to detached screen and get the output - Unix & Linux Stack Exchange for an example on how to send commands to a session. One correct invocation is:
screen -dmS test
screen -S test -X hardcopy screenOutput.txt
I.e. -X shall be the first command option. -d/-r switches to search only attached/detached sessions have to follow it (the docs are notoriously vague on this); in this case, they are not needed at all.
I confirmed this to not work (produce blank file) in screen v4.0.3 and work in v4.2.0 and up in the same environment.
Extensive investigation:
Debugging shows that the root cause is in WriteFile at fileio.c:472 : if (!fore) break; which quits the function without writing anything because fore (a pointer to the foreground window) is indeed NULL.
I couldn't pinpoint the specific commit where this was fixed, but did check that it isn't NULL in v4.2.0. The variable is set in a number of places around the codebase and is reset to NULL in roughly the same amount of places, often in code that follows the assignment. So the chances of a working workaround are very slim.
I hereby reaffirm that in screen v4.0.3, hardcopy is broken and you have to upgrade (e.g. install a version to /usr/local so that it overrides the stock one).
Related
I have a application that launches xterm and dumps uart logs. I am able to see it launch and dump the logs in the GUI. However, Using a remote session I want the xterm output to be running as a background process somewhere so that I can switch back and forth within a single terminal.
Using GUI
Using remote terminal (SSH)
$ xterm
xterm: Xt error: Can't open display: :0
I tried to do something like, but failed to work -
alias xterm="/bin/bash -c"
I don't want to have X forwarding and launch a window on my local machine as well.
If you just need the logs, you most likely don't need an X server or xterm.
You can simply run the target command itself. From your screenshot it looks like the command might be telnet 127.0.0.1 <port_number>. You can find it from the script that your application launches, or with ps -ef when it's running. If it's an UART, then you can also use minicom or socat to connect directly to serial port without any extra programs. This way, you don't even need telnet.
You can combine this command with either screen or tmux so that it's running in the background and you can switch to it from any terminal or console. Just run screen with no arguments, then run the command on virtual screen. Detach with CTRL-a d, and your command will continue to run in the background ready for you to reconnect to it at any time with screen -r.
Moreover, screen can also connect to serial port directly so you get two for the price of one.
The thing with xterm is that it will not write the logs anywhere except in the graphics buffer, and even there it will be only as flashing pixels which is not suitable for any processing. If you insist on going that way, you have several options:
Change the script that application runs (might not be possible depending on your situation)
Replace /usr/bin/xterm with your dummy script that just runs bash instead of xterm, and redirects the output to a file (ugly, but you could probably avoid breaking other applications by changing PATH and putting it somewhere else). In your script, you can use bash's redirection features such as >, or pipe output to tee.
Start a VNC server in the background and set the DISPLAY environment variable when you run your application to the number of virtual screen. In this case, any windows from application will open on VNC virtual screen and you can connect to it as you please.
Use xvfb as a dummy X server and combine it with xterm logging, etc.
Solution 1: Fake xterm on X11-less systems
You can also create a wrapper script that replaces xterm with another function. Test this out on a laptop with X11:
$ function xterm {
echo "hello $#"
}
$ xterm world 1
hello world 1
$ export -f xterm
$ /bin/xterm # opens a new xterm session
$ xterm world 2 # commands executed in second terminal
hello world 2
This means that you've replaced the command xterm for a function in all of the child processes.
Now, if you already know that your script will work in a terminal without xterm, you could create a function that accepts all of the parameters and executes it. No need for complicated screen stuff or replacing /usr/bin/xterm.
Solution 2: Dump UART data for the winz
If you want to save all of the uart data into a file, this is easily fixed by creating a screen session and a log file. Below the command will create a session named myscreensessionname that listens on the serial connection /dev/ttyUSB0 and writes its data to /home/$USER/myscreensessionname.log.
$ screen -dmS myscreensessionname -L -Logfile /home/$USER \
/myscreensessionname.log /dev/ttyUSB0 115200
Note that if you're going to use multiple screen sessions, you might want to use serial ids instead of /dev/ttyUSB0. You can identify the connections with udevadmin as follows.
$ udevadm info --name=/dev/ttyUSB0 | grep 'by-id'
S: serial/by-id/usb-FTDI_TTL232R-3V3_FTBDBIQ7-if00-port0
E: DEVLINKS=/dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTBDBIQ7-if00-port0 /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.4.4.1:1.0-port0
Here, instead of /dev/ttyUSB0, I would make use of /dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTBDBIQ7-if00-port0.
EDIT:
You can attach the screen session with the following command. Once in the screen session, press crtl+a, and press d to detach.
$ screen -Dr myscreensessionname
To view all of your screen sessions:
$ screen -list
There is a screen on:
2382.myscreensessionname (04/02/2021 10:32:07 PM) (Attached)
1 Socket in /run/screen/S-user.
I'm trying to launch a detached screen that has a screenname and also has running commands.
I've seen other posts that say to use screen -dmS ScreenName to create a named screen, then use screen -r ScreenName -X stuff $'MyCommands\n' to give it commands to run.
The problem with this is I want the screen to terminate after my commands are run, but doing the above screen commands separately means MyCommands will execute and then after completed the screen will wait and not terminate.
The problem seems to be creating a screen with a screenname AND with commands.
Any ideas on how to get around this would be appreciated.
Well I couldn't figure out how to do it on one line, but this solution provides me with the same affect I was looking for.
screen -dmS ScreenName
screen -x ScreenName -X stuff $'MyCommands\nexit\n'
The first line creates my screen with a specified name, the second line passes MyCommands to run in the screen, followed by the exit command which ends up terminating the screen after all of my commands have completed.
On Mac OS is it possible to create an Automator/Bash/Java/ApplieScript that runs an bash-command to do something (for example chance the screen resolution) after that runs an application (for example a game that needs a specific screen resolution) then waits until the application has been terminated and after that does one final thing (for example change the screen resolution again)?
I tried to work with all Automator, Bash, Java and ApplieScript. I even tried to combine multiple of them to one chain of things that runs other things just to run something else until it terminates and then run something else, but non of that semms to work properly.
I got the terminal commands that changes screen resolution and I also got the terminal command that runs the Game, but I can't bring it together in an logical correct chain of things to happen...
The Commands are:
do shell script "/Volumes/Sierra/Users/xyz/Documents/cscreen -x 1600 -y 900 -r 60"
do shell script "open steam://run/8930"
do shell script "/Volumes/Sierra/Users/xyz/Documents/cscreen -x 1280 -y 720 -r 60"
What you want is the -W argument for open:
-W Causes open to wait until the applications it opens (or that were already open) have exited. Use with the -n
flag to allow open to function as an appropriate app for the $EDITOR environment variable.
So in your example I would make a script like this:
#!/bin/bash
/Volumes/Sierra/Users/xyz/Documents/cscreen -x 1600 -y 900 -r 60
open -W steam://run/8930
/Volumes/Sierra/Users/xyz/Documents/cscreen -x 1280 -y 720 -r 60
Now open should not return control to the shell until steam exits.
I have a game server running in an xterm window.
Once daily I'd like to send a warning message to any players followed after a delay by the stop command to the program inside the xterm window from a script running on a schedule. This causes the cleanup and save functions to run automatically.
Once the program shuts down I can bring it back up easily but I don't know how to send the warning and stop commands first.
Typed directly into xterm the commands are:
broadcast Reboot in 2 minutes
(followed by a 2 minute wait and then simply):
stop
no / or other characters required.
Any help?
Do you also need to type something from the xterm itself (from time to time) or do you want your server to be fully driven from external commands?
Is your program line-oriented? You may first try something like:
mkfifo /tmp/f
tail -f /tmp/f | myprogram
and then try to send commands to your program (from another xterm) with
echo "mycommand" > /tmp/f
You may also consider using netcat for turning your program to a server:
Turn simple C program into server using netcat
http://lifehacker.com/202271/roll-your-own-servers-with-netcat
http://nc110.sourceforge.net/
Then you could write a shell script for sending the required commands to your "server".
If you know a little about C programming; I remember having once hacked the script program (which was very easy to do: code is short) in order to launch another program but to read commands from a FIFO file (then again a shell script would be easy to write for driving your program).
Something you might try is running your program inside a screen session.
You can then send commands to the session from cron that will be just
as if you typed them.
In your xterm, before launching the program do:
screen -S myscreen bash
(or you can even replace bash by your program). Then from your cron
screen -S myscreen -X stuff 'broadcast Reboot in 2 minutes\n'
sleep 120
screen -S myscreen -X stuff 'stop\n'
will enter that text. You can exit the session using screen -S myscreen -X quit
or by typing ctrl-a \.
screen is intended to be transparent. To easily see you are inside screen, you can
configure a permanent status bar at the bottom of your xterm:
echo 'hardstatus alwayslastline' >~/.screenrc
Now when you run screen you should see a reverse video bottom line. Depending
on your OS it may be empty.
The main problem I'm having is to background a screen session from Hudson-CI. The shell steps are that I need to start a screen session from a script that is launched by another script. Heres' a simple test:
test.sh:
#!/bin/bash
myscreen.sh
myscreen.sh:
#!/bin/bash
screen -dm -S myscreen pingit.sh
pingit.sh:
#!/bin/bash
ping google.com
If I run ./myscreen.sh I get a screen launched that runs the ping continuously without a problem.
If I run ./test.sh, the screen is never started. I'm assuming there's something basic that I'm either forgetting or not understanding, but I can't figure out what. I thought this would work.
The real reason I want to do this is to have Hudson CI launch a continuous-test script which starts as a screen session so that it can continue in the background. What I'm finding is that the screen session terminates once the task is completed in Hudson.
Any ideas on why I can't launch a persistent screen session from a grand-parent script? Or any ideas on how to deal with this?
This is on OSX 10.6, with screen built from source (so it should work the same as linux I think).
If I run your test.sh, I get the error message
./test.sh: Zeile 2: myscreen.sh: Kommando nicht gefunden.
i.e. command not found. You'll have to write ./myscreen.sh, if the current directory is not on the path. (Is it for you? It should not.) The same is valid for the screen call.
Changing both files to
#!/bin/bash
./myscreen.sh
and
#!/bin/bash
screen -dm -S myscreen ./pingit.sh
I can start my screen without any problems.
I'm on Linux (OpenSUSE) with
$ screen --version
Screen version 4.00.03 (FAU) 23-Oct-06
here.
I don't know why I did not find the following references before, but these were the links that helped me solve the problem:
https://serverfault.com/questions/155851/run-gnu-screen-from-script
http://wiki.hudson-ci.org/display/HUDSON/Spawning+processes+from+build
There are 2 issues here - one of screen being persisted after being launched by a grand-parent process. The other that hudson terminates a session after it completes its task.
The screen problem is resolved by zombie'ing the process as follows:
screen -d -m -S myscreen && screen -S myscreen -X zombie qr && screen -S myscreen -X screen pingit.sh
The Hudson-CI problem turns out to be a bug that's easily resolved per the above link. The solution is to add BUILD_ID=something into the shell script. So if the test.sh script from above is actually the Hudson Build shell execute, then it would have to be changed to:
#!/bin/bash
BUILD_ID=dontkillthisprocess
myscreen.sh
Once both of these steps are implemented, things work fine.