Cobra: Writing a bash like shell

[faeronsayn]

Can we do something like the following with this plugin

$ > myapp login
$ > username: ${user_inputs username}
$ > password: ${user_inputs password}
myshell#cur_username > mycommand1 
myshell#cur_username > mycommand2 some_sub_command --a some_args
myshell#cur_username > exit
$ > 

Essentially have a shell that has it's own commands?

[xylonnaise]

I would imagine you would make a child command
which

• runs a for loop to handle the input
• call the function that parses the input for the cobra cli
• throws the user input as one of the parameters.

I'm not sure whether this is right or wrong, but it is one approach.

Update :
Figured it out. This is a vague idea of what you might want to use.

Parse a string into a string array using space as a delimiter, then put it into a string array and do this in a for loop
RootCmd.SetArgs(a []string)
RootCmd.Execute()

SetArgs manually sets the arguments used in Execute

[elliotmr]

I was able to integrate github.com/chzyer/readline with cobra pretty easily. Here is a gist of a shell command that parses the command structure to populate the autocomplete tree and then executes the commands from the readline. (https://gist.github.com/elliotmr/8815e429a91bdc54109eeec9d5a53cbd)

Actually, I think there is an opportunity to clean this up and turn it into another library.

[clintoncampbell]

Currently working on a tool that applies the methodology provided by @elliotmr to simplify management of configuration in AWS Parameter Store. I've posted one small revision as a comment on his gist and will aim to contribute some further examples in the near future.

[clintoncampbell]

Still working on this, though I'm running into challenges that may prompt me to go another direction. Though it's possible to get a basic interactive shell running, the challenge that you will run into is that flags will leak between command invocations. For example, if I set a boolean flag (default false) on one invocation, the next invocation will see the flag as default true since the flag library is built on the assumption that flags are only ever used once.

I've dug through the source for cobra and pflag looking for a workaround, but we're missing a couple of core features that would allow us to clear flag state (and restore defaults) or otherwise fine-tune the behavior of flags between command invocations. I've come fairly close to building this functionality, but each attempt has been thwarted by one design decision or another. For example:

1. Flags do not store default values (default is forgotten once the initial value is changed), so we cannot reset the original value
2. No method provided to elegantly clone FlagSet or Flag. Replicating this approach outside of pflag doesn't appear to be practical since the Value is stored as a pointer and the pflag value types are not exported.

I think I'll be able to come up with a hack solution, but it appears that a good solution would require some changes to the guts of pflag/cobra.

[robertgrimm]

@clintoncampbell Did you ever come up with a good solution to this? We're running into this same issue. We wrote our own interactive shell for Cobra (a for loop that calls SetArgs and Execute for each command) and arguments are leaking to other command invocations. "--help" is the easiest way to reproduce this issue.

[robertgrimm]

I thought I'd leave a comment describing how we finally got around to working around the problem that @clintoncampbell pointed out. What we did was not use the global RootCmd object within the shell's for loop (which wasn't appropriate anyway for our use case since we have persistent flags that are only applicable to the process itself and not commands run within a shell, plus we have commands that aren't applicable once you're in a shell). Instead, we call a function that re-generates a new 'root command' object tree after every single Execute() call within the shell's for loop. I'd much prefer to have a way to reset flags back to their default value but this approach appears to work fine for us at least.

[github-actions[bot]]

This issue is being marked as stale due to a long period of inactivity

[dkozlov]

@robertgrimm is there any solution to this issue in 2020?

[robertgrimm]

@dkozlov I'm still using the same solution I described in my last comment. It's been working well for us.