Wes, I think it would be interesting if we added a new option ‘--output=json’ to better handle the use case you described. Then you could pipe the gfsh command through a json parser like jq.
Anthony > On Nov 4, 2016, at 9:51 AM, Real Wes <thereal...@outlook.com> wrote: > > I call the GFSH Parser from code and rely on the formatting of the return > message to determine the response. So I’d like to see that code as > encapsulated in one place. > >> On Nov 4, 2016, at 11:38 AM, Jinmei Liao <jil...@pivotal.io> wrote: >> >> >> We have several jira issues related to gfsh parsing (GEODE-1598, >> GEODE-1912). After spending some time understanding how the parsing works, >> I found out we have three components intertwined together all trying to do >> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by >> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The >> outcome is I am able to maintain the current parsing and tabbing completion >> capabilities (and fix a few bugs) by removing 40+ files. The only >> difference I see so far lies in the help and hint messages. It seems the >> main reason we are using these home backed Gfsh parsing is to provide more >> readable help messages. Below are the differences: >> >> Using Spring Shell's provided help: >> >> Using Gfsh Parsing with JoptSimple: >> >> >> I do like the outcome of the latter, but added complexity of the code is >> too expensive to bear. So I am asking the community how important it is to >> maintain the current style of help? Can we do with the cheaper way by just >> using whatever provided by the libraries? >> >> Cheers >> >> Jinmei >> >
