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 b

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.