Infinite nesting of subcommands about cli HOT 20 CLOSED

👍

from cli.

👍

from cli.

Looks like I will have to start working on this one

from cli.

+1

from cli.

👍

from cli.

As the 800th person who starred this, do I get a wish granted? ;-) If yes, let's please have this feature implemented. It'd be really useful and it'd complete the core functionality. Thanks!

from cli.

@codegangsta - if you have an idea of how you'd want to approach it, I'd be happy to take a stab at implementing it. I know you're incredibly busy with Martini.

from cli.

I'm ready to help with it too cc @codegangsta @kytrinyx

Katrina Owen wrote:

@codegangsta https://github.com/codegangsta - if you have an idea of
how you'd want to approach it, I'd be happy to take a stab at
implementing it. I know you're incredibly busy with Martini.

—
Reply to this email directly or view it on GitHub
#15 (comment).

from cli.

Aww thanks guys. Please feel free to take a stab at it. I did start playing around with it a little while back

925a312

I believe I got hung up on help text. Let me know how far you guys get and if you get stuck. I will help out in any way I can.

❤️

from cli.

An alternative (and probably quicker/easier) way to approach this would be to offer namespacing in subcommands.

Similar to what the heroku CLI tool does, e.g.

$ heroku keys:add [KEY]

$ heroku keys:clear

Perhaps this covers most of the cases people need nested subcommands for and it may even be easier to read on the command line.

from cli.

I think the Heroku approach is pretty intrusive in terms of design and
implementation (Though I'm aware they're unix lovers). I think cli has
to be the more generic possible, and it implies to be the closer
possible to POSIX and unix classic command patterns.

Plus, using ':' as a separator implies a split operation which appears
to be useless to me as the golang os library already provides a ' '
splitted list of args.

fwl wrote:

An alternative (and probably quicker/easier) way to approach this
would be to offer namespacing in subcommands.

Similar to what the heroku CLI tool does, e.g.

$ heroku keys:add [KEY]

$ heroku keys:clear

Perhaps this covers most of the cases people need nested subcommands
for and it may even be easier to read on the command line.

—
Reply to this email directly or view it on GitHub
#15 (comment).

from cli.

I agree with @oleiade here. Good news is that it is pretty easy already to go the namespaced route currently if you want to. I think the git style nested subcommands should definitely be in this library

from cli.

I am not advocating the Heroku approach, only added an additional idea to the discussion. 👍 for subcommands the way you both describe.

@oleiade Speaking of POSIX, I'm under the impression subcommands are out of the standard anyway (though I may be wrong): http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02

from cli.

Any updates on this?

from cli.

👍

from cli.

I've made some progress with this issue. https://github.com/anaxagoras/cli/commit/597d5c682ca5d8c1cb63f21d733b95b4a0df27e6

There's a little redundant code that I'd like to unify, namely between helpCommand and ShowCommandHelp, and I'm currently working on getting reasonable output so that

$ ./app help cmd subcmd
NAME:
   subcmd - description

USAGE:
   command cmd [command options] [arguments...]

becomes

$ ./app help cmd subcmd
NAME:
   subcmd - description

USAGE:
   app cmd subcmd [options] [arguments...]

But I'm pretty happy with the progress so far. I'll try and get the rest of it done and add some tests sometime in the next couple of days.

from cli.

I found a way to do this using existing functionality:
https://gist.github.com/smousa/9957809

from cli.

nice!

from cli.

Isn't it done in 5a05be4 already?

from cli.

yup. closing!

from cli.