> Bash handles several filenames specially when they are used in redirections, as described in the following table. If the operating system on which Bash is running provides these special files, bash will use them; otherwise it will emulate them internally with the behavior described below.
> ...
> Bash attempts to open the corresponding [...] socket.
Even more fun is that if you create /dev/udp/127.0.0.1 (and chmod a+rwx), it won't create the file 53 if you "echo hello > /dev/udp/127.0.0.1/53". Instead it sends a UDP packet to your DNS server.
If you create a symlink to a path like /dev/udp/127.0.0.1/53 and redirect output to the symlink, a packet is not sent; the file is written as normal.
I'm guessing nobody has ever actually had a problem with this, so it's not actually a bad design choice, but I personally wouldn't have written that code. Leaky abstraction.
st_goliath|3 years ago
https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash....
> Bash handles several filenames specially when they are used in redirections, as described in the following table. If the operating system on which Bash is running provides these special files, bash will use them; otherwise it will emulate them internally with the behavior described below.
> ...
> Bash attempts to open the corresponding [...] socket.
londons_explore|3 years ago
If they persuaded the kernel devs to make some devfs way that those were real files, using the unix filesystem API, also fine.
But making something that looks like a real thing in the filesystem, but isn't usable by other programs that use the filesystem... Thats not right.
jrockway|3 years ago
If you create a symlink to a path like /dev/udp/127.0.0.1/53 and redirect output to the symlink, a packet is not sent; the file is written as normal.
I'm guessing nobody has ever actually had a problem with this, so it's not actually a bad design choice, but I personally wouldn't have written that code. Leaky abstraction.
yakubin|3 years ago