Usability of the NEAR CLI in scripting?

[artob]

❓ What is the plan to make the CLI usable for scripting? Because as it stands currently, that seems rather difficult:

Invoking: near account view-account-summary near network-config testnet now

Invoking: near account view-account-summary notfound network-config testnet now

The specific difficulties encountered here are:

1. The output structure (on stdout) is extremely verbose, clearly meant for humans only, and unstable over time
2. There is spurious extra output being emitted (onto stderr), and there appear to be no CLI options to disable:
   • The "Here is your console command if you need to script it or re-run" tutorial output
   • The "Receiving an inquiry about your account" progress output
3. There appears to be no CLI option (such as --quiet or --silent) for silencing all spurious output
4. There appears to be no CLI option (such as --output json) for printing machine-readable output
5. The error output (all on stderr) has intermixed into it progress output and tutorial output, and is also overly verbose
6. The exit status in case of any error is an undifferentiated exit code 1, instead of something useful such as sysexits(3) exit codes

[frol]

@artob What is your use case? Wouldn't it be easier to use near-api-rs, py-near, or near-api-js instead of shelling out CLI commands?

[artob]

@frol The category of use cases is shell scripting, which is the single largest and most significant category for any CLI tool.

The novel, explicit command structure of near-cli-rs is in principle uniquely well suited to scripting, as compared to most CLI tools including the old JS-based CLI. In fact, arguably near-cli-rs would be even better suited to scripting than to actual use by humans, since for the latter it tends to be rather verbose which goes against the grain for the supermajority of CLI utilities in wide use. However, near-cli-rs's inherent high potential for scripting is right now being held back by the incidental issues identified above.

Suggest it would be a good idea to take a clear decision on whether scripting is supported or not. If not, consider removing "to script it" from the following output printed on every invocation:

Here is your console command if you need to script it or re-run:

[frol]

@artob Thank you for surfacing your experience! I think --quiet and --output json are good suggestions that we can implement relatively easy. Exit codes are harder since that will require to design those first and then implement custom errors to distinguish them.

Just FYI, I also use NEAR CLI for scripting, but I use the scripts interactively - so I setup aliases and finish the command in interactive mode, so I rely on human output.

[artob]

@artob Thank you for surfacing your experience! I think --quiet and --output json are good suggestions that we can implement relatively easy. Exit codes are harder since that will require to design those first and then implement custom errors to distinguish them.

For exit codes, suggest adopting the sysexits(3) standard codes. They are granular enough to be useful discriminators, without requiring tons of work. There isn't really any other comparable set of standard codes.

For a Rust implementation, see e.g. github.com/dryrust/clientele.rs/blob/master/lib/clientele/src/sysexits.rs.

[gagdiez]

I just came to the issues to open a similar one! happy to find yours @artob

@FroVolod would be amazing to have a --silent option, in my case because I get lost in the output! It is simply too verbose right now

[gagdiez]

For example here I am making the exact same action on near-cli-js and near-cli-rs, and the output of near-cli-rs does not fit into my screen