Swiftlint always printing to stderr

[cfilipov]

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.

$ cat linterrs.txt 
Loading configuration from '.swiftlint.yml'
Linting Swift files at path MyTest.swift
Linting 'MyTest.swift' (1/1)
Done linting! Found 0 violations, 0 serious in 1 file.

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 expect queuedPrint() to be used. In fact, I can't seem to find any places were queuedPrint() 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.

[norio-nomura]

There was discussion related to that: #386 and added --quiet option.

[cfilipov]

--quiet doesn't seem to solve the problem, in fact, it's even more confusing.

Before I get to --quiet, let's run the command from my last comment, only this time I enabled a bunch of rules I know will result in violation errors and warnings.

# 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):

$ cat linterrs.txt
Loading configuration from '.swiftlint.yml'
Linting Swift files in current working directory
Linting Swift files at path MyTest.swift
...
Linting 'MyTest.swift' (1/1)
Done linting! Found 11551 violations, 1309 serious in 1 files.

What's even more surprising is that this is what I got in stdout:

MyTest.swift:119: warning: Line Length Violation: Line should be 100 characters or less: currently 122 characters (line_length)
MyTest.swift:132: warning: Line Length Violation: Line should be 100 characters or less: currently 151 characters (line_length)
MyTest.swift:145: error: Line Length Violation: Line should be 100 characters or less: currently 225 characters (line_length)
MyTest.swift:153: warning: Line Length Violation: Line should be 100 characters or less: currently 159 characters (line_length)
MyTest.swift:128:13: warning: Private Unit Test Violation: Unit test marked `private` will not be run by XCTest. (private_unit_test)

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 --quiet:

# intentionally enabled a bunch of rules in config that will result in violation errors
$ swiftlint lint --quiet 2> linterrs.txt 

and the output:

$ cat linterrs.txt
$

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.

[cfilipov]

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:

configuration error: 'conditional_binding_cascade' is not a valid rule identifier

And if I use --quiet, then that is all I get in stderr (plus the suggestions spanning multiple lines, which isn't great). I may be a little late to the party since this decision has already been made several hundred issues ago: but I think the behavior of --quiet should be the default behavior, and there should be a --verbose-errors flag which results in the current behavior.

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.

[norio-nomura]

I have no preference about these behaviors of SwiftLint.
Only I remember that related issue does exist.

But, It's nice if my post helped you. 😄

[c0diq]

I have the same issue with this. Without --quiet, normal strings such as "Loading configuration from ..." are sent to stderr incorrectly.