Responding to "write" messages
Was wondering if anybody knew of a way to capture and recognize incoming write commands to a terminal. I've tried using script -f and then using tail -f to follow the output on a while loop but because the terminal I'm tracing does not initiate the write it does not get outputted. Unfortunately I do not have root permissions and cannot play with the pts or screendump, was wondering if anybody knew a method to achieve this?
Example:
Terminal 1 $ echo hello | write Terminal 2
Terminal 2 $
Message from Terminal 1 on pts/0 at 23:48 ...
hello
EOF
*Cause a trigger from which I can send a return message
I can't think of any obvious way to do this. Here's why...
Your shell receives its input from, and send its output to, some terminal device:
+-----------+
| |
| bash |
| |
+-----------+
^ |
| |
| v
+----------------------+
| some terminal device |
+----------------------+
When write writes to the terminal, it sends data directly to the same terminal device. It doesn't go anywhere near your shell:
+-----------+ +-----------+
| | | |
| bash | | write |
| | | |
+-----------+ +-----------+
^ | |
| | |
| v v
+----------------------+
| some terminal device |
+----------------------+
So, in order for you to be able to capture what is sent by write , you'd need some hook provided by the terminal device itself, and I don't think there is anything you can use to do this.
So how does script work, and why doesn't it capture the write output?
script can't hook into the terminal device either. It really wants to interpose itself between your shell and your terminal, but there isn't a good way to do that directly.
So, it creates a new terminal device (a pseudo-terminal, also known as a "pty") and runs a new shell in it. A pty consists of two sides: the "master", which is just a stream of bytes, and a "slave", which looks just like any other interactive terminal device.
The new shell attaches to the slave side, and script controls the master side -- which means that it can save the stream of bytes to a file, as well as forwarding them between the new shell and the original terminal:
+-----------+
| |
| bash |
| |
+-----------+
^ |
| |
| v
+-----------------+ <=== slave side of pty -- presents the interface of
| pseudo-terminal | an interactive terminal
+-----------------+ <=== master side of pty -- just a stream of bytes
^ |
| v
+-----------+
| |
| script |
| |
+-----------+
^ |
| |
| v
+----------------------+
| some terminal device |
+----------------------+
Now you can see that a write to the original terminal device bypasses everything, just like it did in the simple case above:
+-----------+
| |
| bash |
| |
+-----------+
^ |
| |
| v
+-----------------+ <=== slave side of pty -- presents the interface of
| pseudo-terminal | an interactive terminal
+-----------------+ <=== master side of pty -- just a stream of bytes
^ |
| v
+-----------+ +-----------+
| | | |
| script | | write |
| | | |
+-----------+ +-----------+
^ | |
| | |
| v v
+----------------------+
| some terminal device |
+----------------------+
If you write data to the slave side of the new terminal here, you will see the output show up, because it will appear in the stream of data on the master side, which script sees. You can find the name of the new pty with the tty command from the shell inside script .
Unfortunately, this doesn't help with write , as you probably won't be able to write to it: your login session is associated with the original terminal, not the new one, and write will probably complain that you're not logged in. But if you eg echo hello >/dev/pts/NNN , you'll see that it does show up in the script output.
上一篇: 简单的如果
下一篇: 回应“写”信息