I created a TCP socket and tried to examine its file descriptor. I can list it without a problem:
[/proc/24846/fd]$ ls -al 11
lrwx------ 1 danb danb 64 10-Sep-19 22:58 11 -> 'socket:[38186892]'
But trying to cat
or write to the file fails because the shell cannot find the file all of a sudden:
[/proc/24846/fd]$ echo 'hello' > 11
bash: no such device or address: 11
[/proc/24846/fd]$ cat 11
cat: 11: No such device or address
I don't expect those commands to do anything useful, but at least there should be consistency and the file should be found. So why is it that the shell fails to find the file when doing those particular operations?
To clarify, I'm not wondering how can I communicate with the socket via the VFS, but the reason why I cannot perform file operations on this file.
bind()
in the server andconnect()
in the client. Shell I/O redirection doesn't do this. – Barmar Sep 10 '19 at 21:36open()
system call. – Barmar Sep 10 '19 at 21:39procfs(5)
designers decided to do it. Since trying toopen()
a/proc/PID/fd/FD
will try to re-open the actual file from scratch (instead of just returning adup(2)
ed fd), how could that work with a socket fd, which was not obtained with theopen(2)
, but with thesocket(2)
syscall in the first place? Thence-ENXIO
. – Sep 10 '19 at 21:47