String in stderr also fails filters/validations#648
Conversation
Similar to what was done in #629
|
The fix for the validation running twice here is definitely welcome, good catch. However, I am not totally sure about the "print to stderr is also considered an error".
The printing is simply a way of returning a string, since such a feature does not exist in bash. While I dm not totally opposed to capturing stderr from these validation functions as if it was stdout, I think it dilutes the message and may add confusion. I am on the fence, hoping to either convince you or be convinced otherwise. |
That was also my thought against this solution. I'm convinced that the bashly user should handle external program error messages and print something meaningful to the end user. Instead of changing the behavior here, I think we can make the "validation contract" more explicit in the docs. Then I'm going to open a PR to bashly-book instead. Closing this one. |
|
Cool. This is the documentation - bullet 3 in particular. |
When a validate or filter function prints to stderr it's not considered a failure. I'm assuming such behavior is unintended, therefore I'm sending this PR.
It also does in
lib/bashly/views/argument/validations.gtxa similar thing done in #629, preventing thevalidate_*function from running twice.