[
https://issues.apache.org/jira/browse/HBASE-19770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327567#comment-16327567
]
Josh Elser edited comment on HBASE-19770 at 1/16/18 6:46 PM:
-------------------------------------------------------------
Thanks, Mike. No worries on another explanation.
Our [~appy] introduced the {{interactive}} flag to the shell. "Interactive"
mode was meant to be designed for when a user is sitting in front of the
terminal typing in commands, and "non-interactive" was for when a file of
commands are provided. Non-interactive mode did a few things like:
* Shell exit on first failed command in the file of commands
* Different I/O setup to IRB
* Values returned by command methods
The opposite of each of these are true for the interactive mode:
* Shell does not exit for any failed command
* Commands' return values are not given to the user
My argument is that the latter should still have the ability to "opt-in". For
example, power-users know that they're in a ruby shell and would want to do fun
things like: {{list.each\{|t| disable t; drop t\}}}. I introduced the {{-r}}
option that, regardless of the interactive/non-interactive mode, would cause
shell commands to return values to the user. The default functionality has not
changed.
was (Author: elserj):
Thanks, Mike. No worries on another explanation.
Our [~appy] introduced the {{interactive}} flag to the shell. "Interactive"
mode was meant to be designed for when a user is sitting in front of the
terminal typing in commands, and "non-interactive" was for when a file of
commands are provided. Non-interactive mode did a few things like:
* Shell exit on first failed command in the file of commands
* Different I/O setup to IRB
* Values returned by command methods
The opposite of each of these are true for the interactive mode:
* Shell does not exit for any failed command
* Commands' return values are not given to the user
My argument is that the latter should still have the ability to "opt-in". For
example, power-users know that they're in a ruby shell and would want to do fun
things like: {{\['table1', 'table2'\].each\{|t| disable t; drop t\}}}. I
introduced the {{-r}} option that, regardless of the
interactive/non-interactive mode, would cause shell commands to return values
to the user. The default functionality has not changed.
> `list` shell command does not return an array of table names
> ------------------------------------------------------------
>
> Key: HBASE-19770
> URL: https://issues.apache.org/jira/browse/HBASE-19770
> Project: HBase
> Issue Type: Bug
> Components: shell
> Reporter: Romil Choksi
> Assignee: Josh Elser
> Priority: Critical
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19770.001.branch-2.patch,
> HBASE-19770.002.branch-2.patch
>
>
> Another good find by our Romil.
> {code}
> hbase(main):001:0> list
> TABLE
> a
> 1 row(s)
> Took 0.8385 seconds
> hbase(main):002:0> tables=list
> TABLE
> a
> 1 row(s)
> Took 0.0267 seconds
> hbase(main):003:0> puts tables
> hbase(main):004:0> p tables
> nil
> {code}
> The {{list}} command should be returning {{\['a'\]}} but is not.
> The command class itself appears to be doing the right thing -- maybe the
> retval is getting lost somewhere else?
> FYI [~stack].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
