fix(clarity-cli): Make behavior of eval without .clar file less confusing
#6738
+14
−12
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
…fusing Closes stacks-network#6496. That issue reported that `clarity-eval SPWHATEVER something.clar` hangs forever, but it turns out that that's only half true. What it's in fact doing is waiting for `stdin` input. The Clarity program file name is an optional argument, and if it's not given, the program is read from the standard input instead. In the above example command line, `something.clar` is interpreted as the VM state DB directory instead (which is obviously not the caller's intention). I made three changes: - The usage message now uses the common format where all optional args are wrapped in square brackets and required args are unwrapped: ``` Usage: clarity-cli eval [--costs] [--epoch E] [--clarity_version N] contract-identifier [program.clar] vm-state.db ``` - I also added the info to the help message that without the `program.clar`, things will be read from `stdin`. - And I changed the order of execution so that the contract ID and the VM DBs are handled first, before the program content is loaded. That way, if the user passes a `something.clar` but (incorrectly) leaves off one of the required args, it immediately causes an error, instead of waiting for the program from `stdin` and *then* erroring. I also fixed the VSCode launch settings for clarity-cli.
benjamin-stacks
force-pushed
the
fix/clarity-cli-eval-stdin
branch
from
8eb8bd8 to
4dd4ed0
Compare
Author
|
(I know history rewrites and force pushes are discouraged, but since the original branch brought some weird commits along and I had only just opened this PR, I assume that was still fine) |
Codecov Report❌ Patch coverage is
❌ Your project check has failed because the head coverage (75.96%) is below the target coverage (80.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## develop #6738 +/- ##
===========================================
+ Coverage 70.62% 75.96% +5.34%
===========================================
Files 578 578
Lines 358784 358786 +2
===========================================
+ Hits 253376 272537 +19161
+ Misses 105408 86249 -19159
... and 262 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
Looks good to me too! |
simone-stacks
approved these changes
Dec 4, 2025
Merged
via the queue into
stacks-network:develop
with commit Dec 5, 2025
cf8d685
616 of 622 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #6496.
That issue reported that
clarity-eval SPWHATEVER something.clarhangs forever, but it turns out that that's only half true. What it's in fact doing is waiting forstdininput.The Clarity program file name is an optional argument, and if it's not given, the program is read from the standard input instead. In the above example command line,
something.claris interpreted as the VM state DB directory instead (which is obviously not the caller's intention).I made three changes:
The usage message now uses the common format where all optional args are wrapped in square brackets and required args are unwrapped:
Usage: clarity-cli eval [--costs] [--epoch E] [--clarity_version N] contract-identifier [program.clar] vm-state.dbI also added the info to the help message that without the
program.clar, things will be read fromstdin.And I changed the order of execution so that the contract ID and the VM DBs are handled first, before the program content is loaded. That way, if the user passes a
something.clarbut (incorrectly) leaves off one of the required args, it immediately causes an error, instead of waiting for the program fromstdinand then erroring.I also fixed the VSCode launch settings for clarity-cli.