I've always found working with the jruby part of the hbase shell jarring
because many of the hbase commands don't interact "natively" with jruby
constructs.  Some work was done [1] [2] to make it a little better but it
is in that uncanny half-there half-not-there state.

More inline

[1] https://issues.apache.org/jira/browse/HBASE-5548
[2] https://issues.apache.org/jira/browse/HBASE-7353

On Thu, Aug 14, 2014 at 11:53 AM, Sean Busbey <[EMAIL PROTECTED]> wrote:

Most admin work and much "repair" work happens in the shell.

If a gem makes it super easy for folks to get started with hbase that
sounds good.  It does seem we'd need to haev a gem for each major version's
shelll to maintain compatibility if the gem is hosted separately from the
hbase release though, no?

I have a slight preference for keeping modern.
I believe the shell is one of those intefaces that has stayed relatively
stable through the years -- primarily due to relative neglect.

shell.  Today it is a frankenshell that is partially oo ruby style, and
partially procedural sql-shell-style.  I'd even consider a new "user shell"
that is parallel to the current "hacker" shell, with the goal marginalizing
the current shell for low level repair work.

// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// [EMAIL PROTECTED] // @jmhsieh

 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB