-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sub-sub-commands #22
Comments
+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)" With command_path="$(command -v "sub-$command" || true)" if [ "$command_path" == "" ] if [ ! -x "$command_path" ]; then |
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
the above allows for the following syntax sub acommand <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
but still work with the following syntax sub acommand <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 |
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...
but still work with the following syntax sub acommand <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 https://github.com/jeffreyroberts/sub/tree/sub-sub-commands |
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 called
script
?The text was updated successfully, but these errors were encountered: