The man page for bash says that /dev/tcp and /dev/udp actually can be real files that any program can use, but that if they're absent, it emulates the behavior on its own.

> The man page for bash says that /dev/tcp and /dev/udp actually can be real files that any program can use

But that's really just a bit of wishful thinking -- those files/directories don't exist on any mainstream UNIX OS I'm aware of.

Hey I'm the author. Yes, as far as I know it's just sugar for opening a socket, and there's almost never a file that exists. To treat it as a file, you need to assign a file descriptor to it, which you can then read and write from.

Actually, I don't have that device in my normal shell, mksh, but the command works in bash? Is bash putting things in /dev? That seems rather... bad, to be honest.

Bash isn't putting anything in /dev. It checks to see if those files exist (I've never seen them actually exist though), and if they aren't there, it just parses the string and creates a network connection as though they did exist.

Bash is not even pretending such special files exist: /dev/tcp/somewhere is only an elegant syntactic shortcut for requesting a telnet-like network connected pipe in a context in which a filename is required. For the child process, it's just a file descriptor.

I don't think it's elegant at all. Magically treating special strings in this manner seems like a violation of "everything is a file".

how is this a bash-ism? you mean it's related to linux /dev tree?

No, it's not related to the actual /dev tree. Bash handles redirects to /dev/tcp/* and /dev/udp/* specially if there are no files at those locations.

I didn't know this. This is related: https://stackoverflow.com/questions/7765004/tcp-connection-b...