Bringing the best of Bash scripting to Ruby | Hacker News Reader

Bringing the best of Bash scripting to Ruby

radek.io

23 pointsastro-9 comments

The script I use to disable/enable dnscrypt-proxy (multiple instances behind dnsmasq for HA) https://gist.github.com/steakknife/bf6967e2298b95da29b7

Sample output (tethering):

    0 ~ git:master ❯❯❯ internet_access                                                                            
    Bluetooth DUN:  Bluetooth-Modem  dns 127.0.0.1
    Ethernet:  en0  macaddr xx:xx:xx:...:xx  dns 127.0.0.1
    FireWire:  fw0  dns 127.0.0.1
    Wi-Fi:  en1  macaddr xx:xx:xx:...:xx  dns 127.0.0.1
    iPhone USB:  en4  172.20.10.3/24  router 172.20.10.2  macaddr xx:xx:xx:...:xx dns 127.0.0.1
    Bluetooth PAN:  en3  dns 127.0.0.1
    Thunderbolt Bridge:  bridge0  dns 127.0.0.1
    0 ~ git:master ❯❯❯

Sample output (wifi enable, unassociated, no tethering):

    0 ~ git:master ❯❯❯ internet_access                                                                              
    1 ~ git:master ❯❯❯

This is driven by a non-privileged infinite looping event bash scripts which TCP connects to another pair of bash scripts running as root which can actually make the change because they're listening on two localhost tcp ports.

(I've tried these other event-based app/script utilities and they're fragile and buggy as heck.)

It seems like something Apple, for one, should take on... deprecate AppleScript and use something more common, accessible and make a common, standardized scripting platform far more comprehensively documented in something like Ruby. AppleScript is just too COBOL/Cucumber "English" and poorly documented to be practical for advanced users. (I've been gradually moving all new scripts over to Ruby because Bash scripts are fragile and not as inherently reusable as standardizing on a dynamic languages (like RedHat w/ Python).)

Not to bash <groan> on this, but the real "best" of bash (well, shell scripting in general) is the simplicity with which you can connect processes via pipes. Ruby's metaprogramming foo is strong enough that this should be fairly straightforward to make easy - can we see this please?

One of my favorite Ruby post series of all time:

Pipelines using Fibers in Ruby (1.9)

http://pragdave.me/blog/2007/12/30/pipelines-using-fibers-in...

http://pragdave.me/blog/2008/01/01/pipelines-using-fibers-in...

I swear it was actually a 3-part series, but only 2 parts I can find right at the moment.

Not bad. The syntax is still a bit funky at the end of part 2, but that's a pretty trivial gripe.

The best thing about bash, and by bash I mean sh if we're going to argue and I mean bash if we're not going to argue, is that it's already on every system and you can just plan on being able to use it with no further work. Pipelining is definitely awesome, but you can make furniture out of gluesticks using enough bash (and all those two letter commands that aren't bash but always infect the system along side it)

OK. I'll buy that. I don't necessarily agree, however. It's so trivial to get small programs onto a remote machine that relying on `sh` only because it's there seems like a premature optimization.

It's a tradeoff. There's also nothing stopping folks from rewriting init and rc scripts as Ruby code or (re)writing systemd in Go, Ruby, etc.

Ironically, if the given example was written in pure bash, it would be violating best practices. You don't parse ls line-by-line because you can't make the assumption that filenames will map to lines.

Taking this contrived example at face value, imho, I'd instead place the "best of bash" for the particular task with file globbing.

Ruby scripts ultimately are processes, and there's much borrowed from Perl including `ARGF`. Just don't use the clever Ruby syntax stuff unless one wishes to be bashed <groan 2.0> over the head.

It becomes more of a "what should this program should consume, do and output and feedback" problem... Bash, Ruby, whatever... but aim for some standards, in general.

Furthermore, with Ruby, as a dynamic language with full network capabilities and add-on packages (gems) with other IPC libraries (zmq), there are other structured, efficient serialized service consumer/producer configurations possible rather than only shell commands. There are also background job processing frameworks like sidekiq and parallel job processors like celluloid, parallel and EventMachine.

The future, really (for dev &| ops tasks) in on-demand loaded, micro-services rather than giant, slow frameworks. The glue (say chef code) and one-ofs will likely still be a bunch of Ruby code and hopefully more Ruby code, respectively, too.

Reply on news.ycombinator.com