5 ms·

Udp/tcp connection using pure bash

• appleflaxen 15y ago
  /Wow/. That's incredible. How does the "<>" operator work? I'm familiar with command line redirection, but I've never seen this. To wikipedia!
• a3_nm 15y ago
  This is bash-only, but a similar feature exists in zsh: http://rosettacode.org/wiki/HTTP#Zsh http://rosettacode.org/wiki/HTTP#Zsh
• nknight 15y ago
  Er, what OS is this referring to? My Linux boxes don't have a /dev/tcp or /dev/udp. This sounds like a Plan9ism, but IIRC Plan9's network interface shows up under /net, not /dev. EDIT: Ah, this is truly a Bash feature, some sort of internal hackery. It doesn't depend on the actual existence of tcp or udp devices.
  • justincormack 15y ago
    Exactly my thought. Really don't like the use of /dev/... for something that is not a device.
  • joshbaptiste 15y ago
    Most distributions disable bash /dev/{tcp,udp} by default. You would have to compile bash using --enable-net-redirections.
• rmc 15y ago
  Tis good, but it doesn't show how to read from the connection, only how to send data.
  • gregfjohnson 15y ago
    One way to do this: read line <&456 To see what you got: echo $line
• viraptor 15y ago
  While it's an interesting trick - With no proper timeout / error control, I'd rather see the already bloated bash to be a couple of bytes shorter, than to include that feature. There's 'nc' when it's needed. We're getting quite far from the unix's 'one tool - one simple task' idea.
  • moe 15y ago
    Agreed. These toy-features are especially bitter when you look at how little bash the language has evolved in the past decade. Pretty much every system out there drags a significant baggage of shell-scripts along. Yet there's been barely any improvement on the arcanest of all syntaxes. We keep on painstakingly reinventing ever the same control structures (half-broken lockfile mechanisms, retry loops, miserable support for pid/pgroups, awkward subprocess/fd handling etc. etc.) because for some reason nobody bothers to finally bake them into the shell. It's become so bad that most teams seem to resort to using a different scripting language for complex tasks nowadays. But that comes with its own hairball of problems and imho the de-facto shell-scripting language simply should not fall behind its own problem domain so far that the preferred approach becomes to not use it.
    • veyron 15y ago
      Lets imagine for a moment that cross-platform backwards compatibility is a high priority, and that every change leads to a frustrated group of users running scripts from many years ago. How could you make a destructive change? As an example, this works in bash 3.2 but not 4.0: diff <(awk '{print $1, $3}' file{1,2}) in 3 it expands to diff <(awk '{print $1, $3}' file1) <(awk '{print $1, $3}' file2) whereas in 4 it expands to diff <(awk '{print $1, $3}' file1 file2)
      • moe 15y ago
        How could you make a destructive change? Well, the same way that everyone else does it: by versioning. The simplest approach would be to have /bin/bash2, /bin/bash3 etc., with /bin/bash defaulting to the last (current) unversioned bash release. Then when you write a script that depends on a new feature you'd reference #!/bin/bash3 or whatever. More complex schemes are possible but probably not needed here. It's not rocket science. And as your example illustrates: This kind of versioning is actually needed even in the current (almost stale) development-mode of bash. Its absence is the reason why many people still target sh as the lowest common denominator...