sub-sub-commands #22

Open
eins78 opened this Issue Nov 6, 2012 · 17 comments

5 participants

@eins78

How hard would it be to support sub-sub commands with the same autocompletion and help generation via in-line comments?

I am thinking of something like sub-folders

├── bin                   # contains the main executable for your program
├── libexec               # where the subcommand executables are
   ├── sub-command        # a sub-folder, containing 'sub-command-subcommand' scripts

An example where this would be useful is a script subcommand: One could stash away specialized stuff that should not clutter the commands output.
It would also allow a simple hierarchy without glueing together the script manually.

In the blog post you have the line 37 script basecamp file_usage_summary.
Is this the same kind of thinking or just is it just one subcommand which does more or less the same thing with different arguments which happens to be called script?

@drasill

+1

@qrush

This would be cool, if it follows the same structure (and maybe even calls the same scripts) as the parent directory.

@jeffreyroberts

I love this idea, I am going to take a crack at it

@jeffreyroberts

In the file /sub/libexec/sub ...

Replace

command_path="$(command -v "sub-$command" || true)"
if [ ! -x "$command_path" ]; then
echo "sub: no such command `$command'" >&2
exit 1
fi

With

command_path="$(command -v "sub-$command" || true)"

if [ "$command_path" == "" ]
then
libexec_path="$libexec_path/sub-$command"
export _SUB_ROOT="$(abs_dirname "$libexec_path")"
export PATH="${libexec_path}:$PATH"
command_path="$(command -v "sub-$command-$2" || true)"
fi

if [ ! -x "$command_path" ]; then
echo "sub: no such command `$command'" >&2
exit 1
fi

@jeffreyroberts

ok, I have it working with sub / sub-commands / sub-help

however, I am having trouble getting the help to indent properly

I am going to work on completions now

pull request coming soon =]

@jeffreyroberts

ok, this is came out awesome, I need to do some refactoring, match up some conventions and it will be available =]

@drasill

I'm still interested :)

@jeffreyroberts

Ok, I ended up re-writing it to make it dynamically nestable

├── bin                   # contains the main executable for your program
├── libexec               # where the subcommand executables are
    ├── sub-acommand        # a sub-folder, containing 'sub-acommand-subcommand' scripts
        ├── sub-acommand-bcommand        # a sub-folder, containing 'sub-acommand-bcommand-subcommand' scripts
        ├── sub-acommand-ccommand        # a sub-folder, containing 'sub-acommand-ccommand-subcommand' scripts
            ├── sub-acommand-ccommand-dcommand        # a sub-folder, containing 'sub-acommand-ccommand-dcommand-subcommand' scripts

the above allows for the following syntax

sub acommand <command> [args]
sub acommand bcommand <command> [args]
sub acommand ccommand <command> [args]
sub acommand command dcommand <command> [args]

sub help acommand ccommand dcommand <command>

I have modified the following files, and everything is working as normal, sub, sub,bash, help, commands, completions, didn't touch init or sh-shell

before I do sub.zsh, I am thinking about re-writing this one more time, so instead of the above, we could have something like

├── bin                   # contains the main executable for your program
├── libexec               # where the subcommand executables are
    ├── sub-acommand        # a sub-folder, containing 'sub-subcommand' scripts
        ├── sub-bcommand        # a sub-folder, containing 'sub-subcommand' scripts
        ├── sub-ccommand        # a sub-folder, containing 'sub-subcommand' scripts
            ├── sub-dcommand        # a sub-folder, containing 'sub-subcommand' scripts

but still work with the following syntax

sub acommand <command> [args]
sub acommand bcommand <command> [args]
sub acommand ccommand <command> [args]
sub acommand command dcommand <command> [args]

sub help acommand ccommand dcommand <command>

What do you guys think? Any thoughts, ideas, preference ?

@drasill

I like this.

And I definitly prefer the second version, so that it doesn't make a path like /path/libexec/sub-acommand/sub-acommand-ccommand/sub-acommand-ccommand-dcommand :)

@eins78

I also prefer the second version. It would make it very easy to have different collections of 'subs' and quickly mix-and-match different subcommands without renaming, just drag and drop.

@jeffreyroberts

Preview of second version available at

https://github.com/jeffreyroberts/sub/tree/nested-sub-commands

There are a couple of things I didn't like doing the way I did, give it a test drive, let me know if you find any bugs, I think its solid at this point, but Id like another set of eyes on it before I issue the pull request, let me know if you think I should change the way I am doing anything.... refactor, etc..

@jeffreyroberts

A colleague of mine and I have been discussing how I can reduce redundancy a little more, what I am thinking now is something along the lines of...

├── bin                              # contains the main executable for your program
├── libexec                        # where the subcommand executables are
    ├── sub-acommand        # a sub-folder, containing 'sub-acommand' scripts
        ├── bcommand          # a sub-folder, containing 'bcommand' scripts
        ├── ccommand          # a sub-folder, containing 'ccommand' scripts
            ├── dcommand      # a sub-folder, containing 'dcommand' scripts

but still work with the following syntax

sub acommand <command> [args]
sub acommand bcommand <command> [args]
sub acommand ccommand <command> [args]
sub acommand ccommand dcommand <command> [args]

What do you guys think?

@jeffreyroberts

hrmm, I might be in over my head with this re-write, its going to require quite a bit of re-engineering of the entire app, I am going to take a crack at it, but so far its looking like a serious mission =]

@jeffreyroberts

I gave it a shot, and I am little burnt out from re-writing this 3 times already hehe =] I will wait for yall's feedback before I take another crack at it, for now though, I think the nested-sub-commands branch is perfect as is, it works flawlessly =]

@jeffreyroberts

ok, pull request coming soon, please let me know what you would like me to change if anything

https://github.com/jeffreyroberts/sub/tree/sub-sub-commands

@malvim

This looks interesting.

Any news on this? Is this working at all? Should I clone @jeffreyroberts ' repo insted of basecamp's? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment