Open hal0x2328 opened 4 years ago
Good idea. One request; please update the command help description to indicate there is an optional "verbose" flag that can be called. I don't want to go back to the old CLI interface where there were hidden flags that you had to know.
There's actually no command-line flag to force the showing of the scripts in my patch. It really didn't seem useful to me at all to add that - for the reason you mentioned (yet another option to know about) and because I can't think of a single use-case for showing the script in a search result - it's not like you're going to look at it and say "yeah, there's that contract I was looking for with the byte 0xfe at offset 0x12a" (after manually counting that many bytes in the string).
And usually by the time you've listed around 5 contracts you've already exceeded your scroll buffer max line size so even if there were a use-case for displaying every contract script in the search results it would be hobbled by that limitation as well.
Fair, I agree it's unlikely that you'll ever want to see the script
in a search or anywhere on the prompt. Please do change the PR include the parameters
and returntype
in the normal JSON output. The sc deploy
command is one of the places that prints this information and there this information is useful. I've personally also used contract search
a couple of times to lookup smart contract input parameters. Thanks
What current issue(s) does this address, or what feature is it adding?
Searching the chain for contracts is problematic because the hex script for every matching contract is shown in the search output. Generally when searching, the goal is trying to locate a specific scripthash rather than dump every contract's lengthy script in hex.
How did you solve this problem?
By hiding the contract script output in the search results.
show contract
can still be used to acquire the script hex of a contract, so no functionality is lost.How did you make sure your solution works?
Manual testing.
Are there any special changes in the code that we should be aware of?
No.
Please check the following, if applicable:
make lint
?make test
?CHANGELOG.rst
? (if not, please do)