Feature Idea: Alternate channel inlet via JSON

[vanrein]

After a little getting-to-know, I find cmdparser a very useful extension to plain Cmd. Thank you!

We use cmdparser to define local shells for (micro)services, and this format is unbeatable for administration, certainly with completion facilities. But, now that I'm connecting them, I find myself passing shell commands over backbone connectivity, just so I can reuse the existing shell interface. This way of connecting services is not what most programmers expect or want.

I was wondering how easy it would be to add a parallel inlet, say a onecmd_json(), with an input that holds pretty much a JSON version of the dictionary contents, and possibly flattened out to the simpler forms as well, for optimal compatibility. The output might hold a stdout and stderr variable with the respective stream outputs.

This would be perfect for our GSS-API over AMQP 1.0 backbone, but it's much more general -- I'm writing it up here because I imagined it might be best solved in a generic manner in your cmdparser module. That might help its popularity too :)

[vanrein]

How did I end up in a wrong repository? Apologies.

[vanrein]

I was right, it's a shared repo according to the page that let me here. Confused me.

[Cartroo]

Hello, thanks for your comment. Just for context, the reason why this is s shared repo is primarily because cmdparser was something I wrote as part of building ttrack, a command-line todo manager. If I had been more familiar with Git and GitHub at the time I no doubt would have made them separate repos, but we live and learn! I’d be quite open to splitting them up if that would make life easier.

Frankly I haven’t used either of them for years, but it’s great to see someone finding some utility in the module. Given by this time I’m somewhat unfamiliar with even my own code, could you perhaps add some details as to which class this onecmd_json() would be added to, and how the use-case differs from direct use with the cmd module?

[vanrein]

Hi Andy, Yeah, Git took me some getting used to too :) I'm now reading your code, and find it quite easy to follow. I've forked it because it sounds like you're open to the idea but would like more concrete input than a feature request. That's quite okay with such readable code. I'll be back :)

…

-Rick

[vanrein]

Hey Andy, This is pretty much what I have in mind, documented in ParseItem and example code for Token: arpa2@28b28e2 If you're okay with the general idea I don't mind to continue this work and get it going. I also don't mind if you prefer to take it on though :-D By the way, this idea to use the same setup for shell and microservice JSON would not have been possible, hadn't it been for your clever use of parser-based names for the various words, so thank you! I'm working in a separate branch named "json" so I can send the complete results to you as a Pull Request.

…

-Rick P.S. If you'd like to see the sort of shells I'm building with it, you can have a look here: https://github.com/arpa2/docker-demo/tree/master/demo-identityhub https://github.com/arpa2/docker-demo/tree/master/demo-reservoir https://github.com/arpa2/docker-demo/tree/master/demo-dns This builds towards a hosting stack to replace LAMP with something much more inclined towards identity management and user control over security, privacy and plugin services, http://internetwide.org/blog/2016/06/24/iwo-phases.html We got to add bits and pieces everywhere in order to connect open source tooling :-)

[vanrein]

Hello Andy, Once started, this project took its own course. So the request to point into your code is now a complete patch :) I'm sending you a Pull Request. Would you consider including this additional JSON facility? Let me know if you would like things changed. Knowing that many are sensitive about layout, I tried to mimic your style, hoping not to miss anything. Thanks once more for a very useful cmdparser and its clear coding style! Cheers, -Rick

[vanrein]

I am looking forward to learn if you can accept or reject the PR for addition of JSON (or perhaps let it into a branch) and whether the additional code would end up in a new version in pip.

I made an announcement of how we can use this work, and the protocol we intend to use for remote shell access.

I would like to know what to reference: your master, another branch in your repo, or our own fork. My preference would be to reference your source distribution, of course, and be able to use pip for setting it up everywhere.