Udp/tcp connection using pure bash
tmartiro.blogspot.com
Udp/tcp connection using pure bash
1–10 of 13 posts
Re: Udp/tcp connection using pure bash
#2/Wow/. That's incredible. How does the "" operator work? I'm familiar with command line redirection, but I've never seen this. To wikipedia!
Re: Udp/tcp connection using pure bash
#3This is bash-only, but a similar feature exists in zsh: http://rosettacode.org/wiki/HTTP#Zsh
Re: Udp/tcp connection using pure bash
#4Er, 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.
Re: Udp/tcp connection using pure bash
#5Tis good, but it doesn't show how to read from the connection, only how to send data.
Re: Udp/tcp connection using pure bash
#6While 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.
Re: Udp/tcp connection using pure bash
#7Er, 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.
Exactly my thought. Really don't like the use of /dev/... for something that is not a device.
Re: Udp/tcp connection using pure bash
#8Er, 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.
Most distributions disable bash /dev/{tcp,udp} by default. You would have to compile bash using --enable-net-redirections.
Re: Udp/tcp connection using pure bash
#9While 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.
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.
Re: Udp/tcp connection using pure bash
#10While 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.
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 suppor…
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 diff diff