-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swiftlint always printing to stderr #796
Comments
There was discussion related to that: #386 and added |
Before I get to # intentionally enabled a bunch of rules in config that will result in violation errors
$ swiftlint lint 2> linterrs.txt linterrs.txt text contains similar output to the last run, a bunch of informational data (not errors or warnings):
What's even more surprising is that this is what I got in stdout:
So all the informational status got sent to stderr, and all the warnings and errors got sent to stdout! OK, so now let's try # intentionally enabled a bunch of rules in config that will result in violation errors
$ swiftlint lint --quiet 2> linterrs.txt and the output:
So like last time, errors and warnings are printed to stdout, but this time stderr gets nothing! I'm still reading through the thread in the issue you linked to, but so far I'm not seeing any valid justification how how it's currently behaving. I feel like this is unambiguously wrong. A bunch of informational stuff went to stderr while all the warnings and errors went to stdout. Please tell me I'm misunderstanding something here. Edit: OK I see. In that thread you are saying that violations are not errors. Semantically, they are not errors in the sense that SwiftLint did not fail. The violation "errors" are coincidentally called "errors" but they are actually the expected output of SwiftLint reporting on the files its acting on. OK, I don't know how I feel about that but I understand the rationale. However, you do return a non-zero status code on violation errors, which seems to be inconsistent with your view of what it means to be an error. |
After reading up on the history of stderr and common uses, the intent etc.. it's clear that it's meant for diagnostic messages, specifically things you wouldn't want ending up piped to another program, and style violations do not meet that criteria. I think you are right about style violation errors and warnings going to stdout. That said, I still don't see justification for what's being dumped into stderr. This is the only line I see in stderr that I think actually belongs there:
And if I use Anyway, at this point I'm reasonably convinced that SwiftLint isn't doing anything terribly incorrect. I would prefer a different default but that's a minor point and probably not worth pursuing. I'll close this issue. Thanks @norio-nomura! Edit: By the way, here's an interesting article on the history of stderr. |
I have no preference about these behaviors of SwiftLint. But, It's nice if my post helped you. 😄 |
I have the same issue with this. Without --quiet, normal strings such as "Loading configuration from ..." are sent to |
If you're running SwiftLint as part of some validation process (very likely), then you might think of doing something like this to pull the error output into a error report file:
$ swiftlint lint 2> linterrs.txt
However, it looks like SwiftLint always prints to stderr for all output.
One would expect this file to be empty! Digging through the code a bit appears to validate my claim. I see
queuedPrintError()
used in many places where I would expectqueuedPrint()
to be used. In fact, I can't seem to find any places werequeuedPrint()
is used at all.Was this intentional? Would you be open to accepting a pull request that fixes this? I'd like SwiftLint to be a good Unix citizen and keep my stderr clean.
The text was updated successfully, but these errors were encountered: