Closed eins78 closed 6 years ago
+1
This would be cool, if it follows the same structure (and maybe even calls the same scripts) as the parent directory.
I love this idea, I am going to take a crack at it
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
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 =]
ok, this is came out awesome, I need to do some refactoring, match up some conventions and it will be available =]
I'm still interested :)
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 ?
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 :)
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.
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..
This is also something you guys might be interested in...
https://github.com/jeffreyroberts/sub/tree/sub-plugins https://github.com/jeffreyroberts/sub/tree/sub-plugins-example
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?
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 =]
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 =]
ok, pull request coming soon, please let me know what you would like me to change if anything
This looks interesting.
Any news on this? Is this working at all? Should I clone @jeffreyroberts ' repo insted of basecamp's? :)
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
An example where this would be useful is a
script
subcommand: One could stash away specialized stuff that should not clutter thecommands
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 calledscript
?