DEV Community

loading...

Spooky inter process communication at a distance

urandom
Updated on ・2 min read

I recently needed to write a script that can accept input from another script started with systemd timer. FIFO is a no go because of... reasons (also what's the fun of that :D), which leaves me with this fun hacky solution.

The trick we are going to use is the fact that process' information can be accessed under /proc/[pid]/. For example, we can use /proc/$$/comm to get the complete command line of the current process, and more importantly for us, /proc/$$/fd/0 is the current process' file descriptor 0. And of course $$ is just using shell to get the current process id.

To achieve what we want, we just need to get the pid, then write to the process's stdin. However, it is not as straightforward. We can access file descriptor 0, but writing to it does not write to the process' input per se. Because file descriptors point to a file, be it tty or actual file. When we “write” to /proc/$pid/fd/0 we are actually writing to the underlying file, that does not necessarily mean the input will get sent to the processes, it depends on what kind of file we are talking about, for example, writing to a tty will only print it on screen. As It turns out, a pipe would work perfectly for our case, which means some unfortunate cat abuse.

# script_a.sh

cat | grep -o 'I want input'
Enter fullscreen mode Exit fullscreen mode
# script_b.sh

echo 'did someone say "I want input"?' > /proc/$(pgrep grep)/fd/0
Enter fullscreen mode Exit fullscreen mode

further reading

https://unix.stackexchange.com/a/385948: A great answer for something very similar to what we are doing. It explains which kind of file has what effect when being written to.

Discussion (0)