Udp/tcp connection using pure bash

http://tmartiro.blogspot.com/2012/02/udptcp-connection-using-pure-bash.html

by tmartiro • 14 years ago

36 12 14 years ago

tmartiro.blogspot.com

/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• 14 years ago

This is bash-only, but a similar feature exists in zsh: http://rosettacode.org/wiki/HTTP#Zsh

nknight• 14 years 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• 14 years ago

Exactly my thought. Really don't like the use of /dev/... for something that is not a device.

joshbaptiste• 14 years ago

Most distributions disable bash /dev/{tcp,udp} by default. You would have to compile bash using --enable-net-redirections.

rmc• 14 years ago

Tis good, but it doesn't show how to read from the connection, only how to send data.

gregfjohnson• 14 years ago

One way to do this:

read line <&456

To see what you got:

echo $line

viraptor• 14 years 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.

moe2• 14 years 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.

veyron2• 14 years 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)

Udp/tcp connection using pure bash

Related Stories