Linux has this blitheringly annoying peculiarity that /dev/stdin
won't work with sockets - it is hardcoded to return ENXIO. Try this:
socat TCP-OPEN:localhost:1234 EXEC:cat\ /dev/stdin,nofork
That's a perfectly reasonable command you'd expect to work, and does on basically every system, except Linux. (I'm using cat
as a general example of any tool that opens a filename as the only way for you to specify a specific fd to use.)
The linux kernel is explicitly written to forbid sensible use of /dev/stdin
in this way — see http://marc.info/?l=ast-users&m=120978595414993.
If you only need unidirectional capability, you can buffer the data in a separate process:
socat TCP-OPEN:localhost:1234 SYSTEM:'cat | thingy /dev/stdin'
It's wasteful, and worse, is useless if thingy
is meant to be reading and writing to the same fd, because pipes are unidirectional in Linux.
What are we meant to do? /dev/stdin
simply can't be used on Linux for building pipelines with bidirectional pipes, as far as I can tell, because sockets are the only underlying mechanism on Linux that yield a bidi stream with a single fd to read and write from (unlike a pair of pipes).
cat /dev/stdin
usefully differ fromcat
in the first place, which doesn't try to re-open stdin?-
to mean use stdin for input?proc(5)
. Overloading "-" is a bit nasty, and not every application does it. It's a complete pain that you can't open() /dev/stdin on linux when it's a socket, unlike every other system. I'll may have to hack in the "-" kludge to the application if there isn't a better way to do it.cat|
solution though.