fix(cryptogen): write error output to stderr and use standard exit code

[abhayrajjais01]

Type of change

• Bug fix
• Test update

Description

cryptogen wrote command errors with fmt.Printf (stdout) and exited with os.Exit(-1), which wraps to 255 on POSIX shells. Errors should go to stderr and use a conventional non-zero exit (e.g. 1) so pipelines and scripts behave predictably—similar to other tools in this repo.

Changes:

• tools/cryptogen/main.go -> emit errors via fmt.Fprintf(os.Stderr, ...) and os.Exit(1).
• tools/cryptogen/main_test.go -> TestExecutionErrorRoutedToStderrsubprocess test: malformed config - stderr contains the error line, stdout does not; exit status1`

Additional details (Optional)

Suggested checks:
go test ./tools/cryptogen/
go vet ./tools/cryptogen/

[sachin9058]

Nice improvement outing errors to stderr and using a standard exit code makes the CLI behavior much more predictable, especially when used in scripts.
One small question regarding the test: does it also cover cases where multiple error messages might be emitted, or ensure consistent formatting across different failure paths?
Overall, the change looks clean and aligns well with typical CLI conventions 👍

[abhayrajjais01]

Nice improvement outing errors to stderr and using a standard exit code makes the CLI behavior much more predictable, especially when used in scripts. One small question regarding the test: does it also cover cases where multiple error messages might be emitted, or ensure consistent formatting across different failure paths? Overall, the change looks clean and aligns well with typical CLI conventions 👍

It doesn’t try to simulate multiple independent error emissions in one invocation - today cryptogen still exits on the first fatal error returned to main(), so there is not really a batch of unrelated errors printed in sequence from that wrapper
Adding table-driven subprocess cases for additional failure exits (or golden-file checks on stderr wording) could be reasonable follow‑ups if we want tighter guarantees - happy to tackle that here or as a separate small PR if maintainer @mbrandenburger thinks it resonable

Thanks for suggestion

[sachin9058]

The tool exits on the first fatal error, multiple error emission isn’t really applicable here.

I like the idea of adding more table-driven subprocess cases or golden checks as a follow-up for stronger guarantees. Happy to see this evolve further 👍