Please support return codes

[TNing]

Dear all,

First of all: Thank you Samuel Lucas for creating such a nice tool. That kind of tools are quiet rare and I love the way you care about the details (especially when it comes to cryptography).

I currently try to use your tool for automation purposes and - as far as I can see - it does not support return codes (signalizing the OS that something went wrong).

I propose to add some return codes

e.g. DigitalSignatures/FileSigning.cs:80:

Environment.Exit(-1);

Best regards
Markus

PS: I'm not a C# developer so please excuse me if the example above is wrong.

[samuel-lucas6]

Thank you for the kind words. Yep, Kryptor currently doesn't return any error codes. I've not thought about it at all actually.

It seems like a good idea, but it could be quite messy to implement.

1. The code is not designed in a library fashion because that was never a goal. Perhaps it should've been for this sort of reason and improved testing.
2. Multiple files can be processed at once and things continue if there's an error at the moment. Terminating immediately would mess with the human-operated use case, and continuing would require storing and passing around lots of integer returns. Then do you return specific error codes or just one for failure and one for success?

So, it's a tricky one. Maybe I'm exaggerating how difficult this would be, maybe not. I've never experimented with error codes.

[TNing]

I agree with you about the amount of work it takes to implement this cleanly and without any side effects. I bet you end up implementing Exceptions in most parts of your code which get caught and translated into exit codes at "top level". The advantage is then, as you stated, that the code is already prepared for unit testing.

As for me, I love being done with this part of the job ;-)

Considering the different error codes I think: two error codes are better than no error codes ;-)

From my very simple point of view there should be two modes:

• interactive mode (default)
• batch mode (non-interactive, command line switch: --batch)

For the "batch mode " I would prefer the default behavior to be "exit on first error". If you want to change that behavior you can use the cmd line switch:

--treat-errors-as-warnings

Perhaps this is a bit too simplistic.

[samuel-lucas6]

For the "batch mode " I would prefer the default behavior to be "exit on first error".

This could be done via if (Globals.Batch) { Environment.Exit(-1); } in every try catch block for exceptions.

If you want to change that behavior you can use the cmd line switch: --treat-errors-as-warnings

This is actually easier than I thought; you can set Environment.ExitCode rather than managing/returning integers.

Instead of two additional options/switches, perhaps the default behaviour can be to provide an error code if any exception occurs but continue, and --batch can immediately exit with an error code. -1 for error and 0 for success like libsodium.

Perhaps this is a bit too simplistic.

I hope not!

[samuel-lucas6]

@TNing I've done a commit so any error or exception should result in a -1 exit code in v4.

As for --batch, it becomes more complicated. If I was to replicate GPG's option, it would mean interactive commands wouldn't be allowed. However, that would conflict with the above. --batch would then only be able to terminate on the first error.

So, it's either:

1. That approach and then adding another option like --treat-errors-as-warnings, which I don't want to do.
2. An option like -f|--fail-fast. Then it doesn't reject interactive commands, and the naming/its existence is not very appealing either.

Thoughts?