I'd like to disagree, because that aren't errors.

"Bug fix? Yes" -- which one? 😕

stderr is not only for errors, though the name can be misleading for the uninformed. Unfortunately there isn't a whole lot of reading material readily available on the subject. But can I suggest you readthis and then let me know if you still think this PR is bad?

Primary I don't understand, what this PR solves. If you want to redirect the output you are usually not interested in a progress bar and interaction at all and so I'd expect--no-interaction-/--no-progress-flags.

Also I think that some tools (in my opinion) misusestderr for something else than errors doesn't make it right. In some seldom cases there is no way around [1] and that's fine. But I don't think that's the main use-case.
I'll read your link and we'll see what I'll think afterwards :)

[1] For examplecurl, which by default usesstdout for the response and one usually redirects this into a file. Of course you don't want to keep this in your file.

Also I think that some tools (in my opinion) misuse stderr for something else than errors doesn't make it right. In some seldom cases there is no way around [1] and that's fine. But I don't think that's the main use-case.

Take this for instance:

$ curl --user Joe http://someprotectedsite.com/file.tar.gz > erp.tar.gz

cURL will now (correctly) prompt for the password onstderr, which makes total sense.

The Unix philosophy where you have specialized, simple command line tools is about building pipelines. You can only build pipelines if yourstdout output is predictable and focused or else the entire thing won't be very powerful.

What about$output->write() and$output->writeln()?

Should there also bewriteInfo() orwriteError() (orlog()) methods on OutputInterface, which default to stderr?

While it might be convenient, I do think it should be up to the user to use the proper output (stdout vs. stderr) when callingwrite() and such. No need to add more helpers here imho.

Chris Fidao explains this quite well alsohttp://fideloper.com/laravel-symfony-console-commands-stderr

Thanks, nice link :-).

👍

I wouldn't change this in 2.3 but only in 2.7/2.8 as it might have side effects. Also in later version there are alot more classes that would need to be adjusted as well like the ProgressBar class to be consistent.

Also I feel this is the developers task to pass the correct output to these classes. It's not the responsibility of the classes to magically use a different output. It goes against the single responsibility principle.
What if somebody actually wants to use the stdout? It would magically change it. And who determines which helper is considered pertinent and which not?

What if somebody actually wants to use the stdout? It would magically change it.

Aye, there is something to be said for that as well.

I think it would help convention if stderr was the default, but it would certainly be nice if this could still be switched out for stdout instead. Not sure how to resolve that approach properly though. Thoughts?

Many people do not know the history of unix file descriptors and best practices, so it is not clear that stderr should be used for informational messages. Considering that, we might want to reconsider this PR.
My previous argument was that it makes it impossible for people to actually use stdout if they want to. But there is a workaround: In this edge case they can just create anew StreamOutput(STDOUT) and pass that to the helpers instead of the ConsoleOutput.

@Seldaek what do you think?

@Tobion well, IMO there are literally no reasons to ever write a question or interactive thing on STDOUT, so I don't really see it as a problem either way to default to the right thing (STDERR), and yes if you really want to force it to be STDOUT you can still do it as you say.

@alcohol can you create a new PR please?

With the same approach? (sorry I was not following the latest additions to the discussion)

This one could just be reopened/merged no?

Yes same approach. Cannot be reopened because repo was deleted.

I don't have my fork anymore. So no...

https://patch-diff.githubusercontent.com/raw/symfony/symfony/pull/13730.patch should ease the work ;)

Do you still want me to base this off of 2.3 though?