{"id":724,"date":"2026-05-22T19:31:16","date_gmt":"2026-05-23T03:31:16","guid":{"rendered":"https:\/\/salemdata.net\/johnpress\/?p=724"},"modified":"2026-05-22T19:31:16","modified_gmt":"2026-05-23T03:31:16","slug":"a-better-way-to-record-timed-linux-terminal-sessions","status":"publish","type":"post","link":"https:\/\/salemdata.net\/johnpress\/?p=724","title":{"rendered":"A Better Way to Record Timed Linux Terminal Sessions"},"content":{"rendered":"

Timed Terminal Captures with script<\/code>, timeout<\/code>, and a Future Launch Time<\/h2>\n

I recently needed to run the same command on two separate Raspberry Pi Zero 2W systems at almost exactly the same time. Both machines were disciplined to the same local stratum-1 time server, so their clocks were already close enough, e.g. less than 1 second off, for the experiment.<\/p>\n

The real problem was not merely starting the commands at the same time. The problem was capturing the terminal sessions cleanly.<\/p>\n

I wanted the captured script(1)<\/code> output and timing log to contain only the command I cared about, not the setup, not the countdown, not the time it took me to move from one SSH window to another, and not any manual cleanup afterward.<\/p>\n

The solution was simple once the pieces were put in the right order.\u00a0 Here’s the command I used:<\/p>\n

script -q -f -e --log-timing timing.log -c 'timeout -k 5s 60s .\/program' output.script\r\n<\/code><\/pre>\n
The important trick is that the waiting happens outside<\/strong> script<\/code>, and only the actual timed command runs inside<\/strong> script -c<\/code>.<\/p>\n
That means:<\/p>\n
wait until target time  ->  start script capture  ->  run timeout command  ->  program exits  ->  script exits\r\n<\/code><\/pre>\n
No manual exit<\/code> is needed. No extra shell prompt is captured after the program finishes. The timeout<\/code> command terminates the program, and then script -c<\/code> exits because its child command has completed.<\/p>\n
This produces two useful files:<\/p>\n
output.script\r\ntiming.log\r\n<\/code><\/pre>\n
The first contains the terminal output. The second contains the byte timing information needed by scriptreplay<\/code> or by custom replay tools.<\/p>\n
For a synchronized two-machine run, the workflow becomes something like this.<\/p>\n
On the first machine:<\/p>\n
.\/makescript_at.sh little_boy_blue 18:45:00 60s -- .\/little_boy_blue\r\n<\/code><\/pre>\n
On the second machine:<\/p>\n
.\/makescript_at.sh childrens_hour 18:45:00 60s -- .\/childrens_hour\r\n<\/code><\/pre>\n
Each shell can be prepared ahead of time. Each wrapper waits until the specified launch time. The terminal capture starts only at the launch moment. The command runs for the requested duration. The capture then closes automatically.<\/p>\n
For experiments, demonstrations, debugging sessions, and blog-ready terminal captures, this is a very clean pattern.<\/p>\n
The broader lesson is this:<\/p>\n
Do not start script and then wait.\r\nWait first, then start script around the exact command of interest.\r\n<\/code><\/pre>\n
That one ordering decision keeps the capture clean, repeatable, and easy to replay.<\/p>\n
Here is an example of two script sending poems to each other with a 10 second pause after the transfer is completed and then the transfer is started all over again.<\/p>\n