Closed rsenden closed 2 years ago
I do like the idea of having a swiss-army like option. I guess the only concern I how confused the user might get when seeing an option like this. I also imagine that the help information that fcli provides would look quite intemidating and verbose.
This is definitely going to be "easy and simple" once you understand it, but it will probably take a bit of time and effort for an end user to understand this syntax that we're looking is doing and because this is not something that most other CLI tools do, this will look quite foreign.
So again, I personally like this idea, and I would definitely use it. I just have doubts that many of our users will quickly understand how to construct a valid argument for the --fmt
option.
But who knows, maybe something like this can set a new trend in the the world of CLI tools. 😉
Actually, kubectl
uses a similar approach for specifying additional arguments for output formats, like -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
. Note though that we can't use the (exact) same approach for specifying JSON path expressions (as being discussed in #102), as --json-path
in fcli
can be specified for all output formats. Of course, we could do something like --fmt table=col1#col2;jsonpath=...
, but maybe that's becoming too complex.
Maybe we should support a dedicated jsonpath
output format though, allowing people to output a single attribute value for example (although you can accomplish more or less the same with something like --fmt table-headless=some.property.name
, but jsonpath would allow for more flexibility like getting a particular value from an array of objects)
Question from me. Seeing as a jsonpath can be used regardless of which output format a user chooses, why would we want for jsonpath itself to be treated an an output format rather than maintaining the dedicated --json-path
option that we already have?
Original idea has been implemented. Remainder of the discussion not relevant for now; new issue should be opened if any of the items discussed need to be implemented.
Given that
--fields
eventually affects the format of the output (i.e. what columns/properties are displayed), we could consider condensing these two options into a single--fmt
option like in the following examples:--fmt table:col1#col2#col3=project.name
--fmt json:att1#att2.sub3
We'll need to decide on what character make most sense for each of the separators (separating format from fields, separating individual fields, and separating column name from JSON attribute name. For reference,
--fields
currently takes the following format:--fields inputAttr:outputAttr#project.name:Project Name#inputAttr2