3 ms·

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 s

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.

zeroimpl 4y ago
I dunno, if you “echo foo > /dev/null” then “cat /dev/null” you won’t get foo back. Plenty of assumptions about filesystem behaviour don’t work in all cases. That being said, I’d prefer if the symlink actually worked and sent the packet.
- deleted 4y ago
  [deleted]
- jrockway 4y ago
  Yeah when I was testing it, I definitely half-expected the symlink to work. I will quibble with you on /dev/null a little bit. /dev/null works like any other file; there is absolutely no guarantee that you can read what you wrote on any filesystem write on UNIX. You can "echo foo > regular_file" and then "cat regular_file" and it could be gone or have completely different content. Other processes writing the file, network filesystems, quantum rays, who knows. So to me, /dev/null is not unusual in that respect at all, except that that probability function that you can read what you wrote looks a little different than a regular file. Most importantly, /dev/null isn't a construction implemented by bash. Any program on the OS sees the same behavior as your shell script. That said, this isn't really as unusual as I originally thought. You can open a file named $HOME/foo in bash and that's going to be a very different file in your C program. I do like the $ to indicate "hey this is a quirk of the programming language that's allowing this", though.
elteto 4y ago
That’s probably because bash is only looking for those types of paths in a redirection context. But if you try to use regular file utilities those paths don’t have any special meaning so they just work as normal.

zeroimpl 4y ago

I dunno, if you “echo foo > /dev/null” then “cat /dev/null” you won’t get foo back. Plenty of assumptions about filesystem behaviour don’t work in all cases. That being said, I’d prefer if the symlink actually worked and sent the packet.

deleted 4y ago
[deleted]
jrockway 4y ago
Yeah when I was testing it, I definitely half-expected the symlink to work. I will quibble with you on /dev/null a little bit. /dev/null works like any other file; there is absolutely no guarantee that you can read what you wrote on any filesystem write on UNIX. You can "echo foo > regular_file" and then "cat regular_file" and it could be gone or have completely different content. Other processes writing the file, network filesystems, quantum rays, who knows. So to me, /dev/null is not unusual in that respect at all, except that that probability function that you can read what you wrote looks a little different than a regular file. Most importantly, /dev/null isn't a construction implemented by bash. Any program on the OS sees the same behavior as your shell script. That said, this isn't really as unusual as I originally thought. You can open a file named $HOME/foo in bash and that's going to be a very different file in your C program. I do like the $ to indicate "hey this is a quirk of the programming language that's allowing this", though.

elteto 4y ago

That’s probably because bash is only looking for those types of paths in a redirection context. But if you try to use regular file utilities those paths don’t have any special meaning so they just work as normal.