From: David Masover <ninja@...>
Date: 2010-08-18T03:36:38+09:00
Subject: Re: Unix Philosophy in Ruby Programing

On Tuesday, August 17, 2010 04:44:10 am R.. Kumar 1.9.1 OSX wrote:
> David Masover wrote:
>
> Another issue with calling Unix commands is portability. I've finally
> begun converting my shell scripts to ruby since the parameters and
> output across unices do not match. e.g. OSX's BSD commands differ *a
> lot* from the GNU coreutils ones such as 'date', 'expr', and sleep.

This is solvable -- there is enough in common, and GNU coreutils are 
themselves portable. I'm not convinced that this is more of a problem than 
porting Ruby code, particularly Ruby C extensions, between versions and 
implementations of Ruby.

If Nokogiri can use either libxml (on MRI) or Apache Xerces (on JRuby), I'd 
think we could write Ruby abstraction layers for different shell commands, 
especially when the inconsistencies are often minor -- but we don't do that.

So, as I said, portability is a nice side benefit of Gems over commands, but I 
don't think it's why we shy away from using commands.

I could be wrong, though -- I think grit is a counterexample. Git is portable, 
and there's no libgit, so grit seems to just call git. I would guess this is 
done because:

 - Writing a libgit would be much harder than speaking Unix to Git.
 - The Git commandline interface is particularly well-designed.
 - There's only one implementation of the 'git' command.

So portability does factor into it, but I would also guess that if a libgit 
existed, someone would port grit to that instead.

> Anyway, for more of Unix philosophy in ruby, there is a presentation of
> the "GLI" project - helps to create application with multiple
> subcommands such as github.

That's not a Unix philosophy, that's a Unix commandline interface.