scan --workers below 1 is now a usage error. sfdupes prints one line on stderr (Error: --workers must be at least 1, got 0) and exits 2 before it opens the database. Before this change, runScan raised the value to 1 without saying anything. That clamp is gone. The check runs in the scan command's PreRunE, so the error takes the same path through run as the other usage errors. README.md §scan mode states the rule next to the existing runtime.NumCPU() default, and §Error handling lists the case under exit 2.
Things the diff does not show:
Unlike the other usage errors, this one prints no usage text after the message. The issue asks for a one-line error, so the check turns the usage text off for this error only.
runScan now relies on its caller. With fewer than 1 worker it would start no workers and hang. Its doc comment says so. Its only callers are the scan command and tests that pass 4.
Cobra checks for a PATH operand first, so scan --workers 0 with no PATH reports the missing operand.
Judgement call: a bad value that is not a number, such as --workers abc, still gets cobra's own error followed by the usage text, as before.
Model: opus-5-5
`scan --workers` below 1 is now a usage error. sfdupes prints one line on stderr (`Error: --workers must be at least 1, got 0`) and exits 2 before it opens the database. Before this change, `runScan` raised the value to 1 without saying anything. That clamp is gone. The check runs in the `scan` command's `PreRunE`, so the error takes the same path through `run` as the other usage errors. `README.md` §`scan` mode states the rule next to the existing `runtime.NumCPU()` default, and §Error handling lists the case under exit 2.
Things the diff does not show:
- Unlike the other usage errors, this one prints no usage text after the message. The issue asks for a one-line error, so the check turns the usage text off for this error only.
- `runScan` now relies on its caller. With fewer than 1 worker it would start no workers and hang. Its doc comment says so. Its only callers are the `scan` command and tests that pass 4.
- Cobra checks for a `PATH` operand first, so `scan --workers 0` with no `PATH` reports the missing operand.
Judgement call: a bad value that is not a number, such as `--workers abc`, still gets cobra's own error followed by the usage text, as before.
Model: opus-5-5
A --workers value of 0 or less used to be quietly raised to 1, so a
typo ran the whole scan on one worker with nothing on stderr to say
why. scan now refuses it before anything is scanned: one line on
stderr and exit 2, like the other usage errors. The clamp in runScan
is gone, and README states the rule and the default.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
scan --workersbelow 1 is now a usage error. sfdupes prints one line on stderr (Error: --workers must be at least 1, got 0) and exits 2 before it opens the database. Before this change,runScanraised the value to 1 without saying anything. That clamp is gone. The check runs in thescancommand'sPreRunE, so the error takes the same path throughrunas the other usage errors.README.md§scanmode states the rule next to the existingruntime.NumCPU()default, and §Error handling lists the case under exit 2.Things the diff does not show:
runScannow relies on its caller. With fewer than 1 worker it would start no workers and hang. Its doc comment says so. Its only callers are thescancommand and tests that pass 4.PATHoperand first, soscan --workers 0with noPATHreports the missing operand.Judgement call: a bad value that is not a number, such as
--workers abc, still gets cobra's own error followed by the usage text, as before.Model: opus-5-5
Review passed.
Model: opus-5-5
e932aaef0dto75bfc27b26Rebased onto
next; only theTODO.mdentry conflicted.Model: opus-5-5