I think the Bash documentation is somewhat misleading on this topic. Looking at the code, even going back to version 2.04 where network redirections were introduced, /dev/tcp and /dev/udp works as follows:
- at build time, the
configure script checks to see whether various networking features are supported; if so, if network redirections are enabled (which is the case by default), internal networking code is built in;
- at run time, if the internal networking code is built in,
/dev/tcp and /dev/udp (in the right format) are handled internally; otherwise, a warning is produced (“/dev/(tcp|udp)/host/port not supported without networking”) and Bash attempts to open the given path on the system;
- if network redirections are configured out, nothing special is done.
What this boils down to is:
- if network redirection is enabled:
- if networking is supported on the target platform,
/dev/tcp and /dev/udp will always be handled internally;
- otherwise, Bash will warn and try to open the file “blindly”; if the system somehow supports
/dev/(tcp|udp)/host/port, that will be used, otherwise in all likelihood the redirection will fail;
- if network redirection is disabled, no special handling is performed; as above, if the system somehow supports
/dev/(tcp|udp)/host/port, that will be used, otherwise in all likelihood the redirection will fail.
/dev/tcp does exist on some systems, but as far as I’m aware none support the same abstraction as Bash. On Solaris, /dev/tcp is used with the ndd tool to query and change network configuration. In XTI (see also the Open Group if you’re a member), the t_open function can be used with /dev/tcp to open a TCP connection, but it doesn’t use path-based setup, there’s a separate data structure to specify the target host and port (and other parameters).