1

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?

user1763510
  • 1,070
  • 1
  • 15
  • 28
  • Related: http://stackoverflow.com/questions/4807474/copying-gnu-screen-scrollback-buffer-to-file-extended-hardcopy – ivan_pozdeev Mar 22 '16 at 02:33
  • This works with version 4.03.01, any idea how to get it to work with 4.00.03? – user1763510 Mar 22 '16 at 15:04
  • 1
    Looking at the git log, [there have been a few fixes for `hardcopy` since 2006](http://git.savannah.gnu.org/cgit/screen.git/log/?qt=grep&q=hardcopy), so it may very well be broken in`4.00.03`. You might wish to step through the source to check if it writes bogus data or just takes a wrong path. – ivan_pozdeev Mar 23 '16 at 23:57

1 Answers1

1

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).

Community
  • 1
  • 1
ivan_pozdeev
  • 33,874
  • 19
  • 107
  • 152