Will take a look ASAP; thanks!

What to do with the Commands that use the Symfony ConsoleOutput? Something like the following?

$output->writeln($messages)

becomes

$output->getErrorOutput()->writeln($messages)

Should we then hint ConsoleOutputInterface? Or have a wrapper that does an instanceof check and delegates accordingly?

The typehint breaks a lot of tests. Not sure if I should clean up the tests, or change the approach. Feedback?

Yeah I guess this has to be reverted.. I think it should work if you just replace $output->writeln by $this->getIO()->write[Error]

I need some more time to review in detail, but here is a preliminary list that I think should output to stdout. Everything not on this list, including warnings, notices about outdated versions in the commands below etc should go to stderr:

• composer config when getting a setting or when using --list
• composer depends probably without the headers which should go to stderr (might need a more "condensed" more for grepping)
• composer licenses (might need a more "condensed" more for grepping)
• composer search
• composer show (could maybe default to -N when stdout is not a TTY but likely shouldn't)
• composer status

A few good rules for figuring out if something should go to stdout or stderr is:

• if everything is fine, don't output anything to stdout unless that's the point of the command (e.g. composer show)
• any composer command, in particular if it returns data, should be able to be in a pipeline like composer config --list | grep foo, and a sudden "this version of Composer is over 30 days old" should not break this pipeline, so it has to go to stderr.

In general, Composer will need quite a bit more Unix love. Run any command through | more and see how the color codes mess stuff up; I guess --no-color should be the default if stderr is not a TTY. Or run a script that outputs to stderr, exits with code 0, and then is treated as failed (I think) because it output to stderr, which really isn't an error condition.

Also, composer --version should echo the version string to stdout, but warnings to stderr. composer --help and any usage info should always go to stderr.

Any idea how to explain this?

$ bin/composer status
No local changes

^ the response is in green (color codes)

$ bin/composer status | more
ESC[32mNo local changesESC[39m

but...

$ bin/composer status 2>/dev/null | more
No local changes

BTW "No local changes" should be stderr as far as I understand.

As for how color usage is determined by default, AFAIK it is done here:

https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Console/Output/StreamOutput.php#L101

It seems this is always true though here:

$ php -r 'var_dump(posix_isatty("php://stdout"));' 2>/dev/null | more
bool(true)
$ php -r 'var_dump(posix_isatty("php://stdout"));' | more
bool(true)
$ php -r 'var_dump(posix_isatty("php://stdout"));'
bool(true)

Not sure what's up on yours.

@dzuelke this should solve some color issues as well: symfony/symfony#13661

Correct, "no local changes" from composer status should go to stderr; if there are changes listed, then those should to to stdout I guess.

Keep up the great work on this, @alcohol!

@dzuelke One thing I've come across frequently while doing some reading myself is the following, "stderr is also the place where you print stuff like help docs when an invalid argument is passed to a command" with the exception being "when asking explicitly for help docs they should be printed to stdout". Personally I also feel that makes sense. Do you agree?

Edit: I specifically mean the exception here.

On a side note, do you use IRC by chance? If so, drop me a line sometime on freenode (ethanol).

Yes, I'd also print to stderr stdout if the help screen for any command was explicitly requested. Seems most Unix-y programs do that.

But then wouldn't that stop you from doing for example command --help | grep X ?

If you do a checkout and run grep -irPC 3 'io->write\(|getio\(\)->write\(' src you should get a picture of what is left going to stdout.

I'm not sure on the following cases:

• AboutCommand - expected output, so stdout?
• DiagnoseCommand - mostly (even warnings and errors) expected output, so stdout?
• InitCommand - not sure about this.. lot of user interaction stuff, not likely to be used in a piped process
• Util/[Git|Svn] - the prompt for authentication, followed by user input, should that be stderr or not?

As for help going to stderr, I'd either have to overload the default command from SF2, or submit a PR and cross fingers that they accept it (which might not be the case).

Sorry I meant stdout of course for explicit help!

• AboutCommand - expected output, so stdout?

👍

• DiagnoseCommand - mostly (even warnings and errors) expected output, so stdout?

Good question. I was going to say that e.g. the xdebug warning should go to stderr, but then the output of the command is mostly useless because there is no context. I guess stdout is fine.

• InitCommand - not sure about this.. lot of user interaction stuff, not likely to be used in a piped process

Well that command is completely quiet (like it should be) when running using -n, so the prompts (and any associated status messages) should go to stderr I think.

• Util/[Git|Svn] - the prompt for authentication, followed by user input, should that be stderr or not?

Absolutely!

Aside from InitCommand, pretty much everything should be in order now. I'm personally conflicted about InitCommand. I feel that the interactive session with the user should mostly belong on stdout. But if you guys prefer stderr, I'll replace it. Let me know.

/cc @dzuelke @Seldaek for feedback

@josegonzalez assuming this means you are making non-standard assumption, because there is no convention about the way to use output to report failures. Detecting failures is based on the exit code only in CLI conventions (it is even something being common to both Unix and Windows systems).

stderr vs stdout is not about error report vs non error report (btw, I don't think that shell scripting calls them stdout and stderr at all). They are about message being part of the command output (i.e. something you would pipe to the next command in the chain) vs message not being part of it (informational messages for the user, and error reports are a specific kind of informational messages: they inform of an error)

As used here, while we should definitely check the status code, it's common to assume that any output to stderr is error output and thus users using composer in tooling may be confused as to whether their command is failing or not. I know it's a bad example because of the message itself, but would it be possible to instead move to proper log levels?

That's a wrong assumption. Try a curl https://google.com/ > google.txt. The standard error stream is not just for errors. Please use the exit code of a process to determine its success or failure. These are standard Unix conventions, and mixing diagnostics/progress/informational output with the "real" output of a program breaks the whole concept of Unix pipelines, unless you like spending your evenings messing around with awk and sed scripts to parse output from badly written applications.

I'm not saying that it's the right way to do this, and the example I give is a bad one. This is probably a philosophical issue, but here is a better example.

I'm the maintainer of multiple vagrant installs at my company, and we manage things through chef. I have it setup so that if chef executes a command which has error output, that is always output in red. Very useful for debugging, and you or I can easily see that the message above is not an error but status output. I would see that error and silence stderr because it's not actually an error, and is going to be confusing to users.

Now imagine I give vm access to someone else on the team, a frontend dev, who has no idea how any of the tooling below vagrant works. All they know is about npm and gulp. They bring up the vm, there is an issue with composer failing, but no error output because I silenced status output earlier. They come to me with their issue and now we have to turn on stderr, which happens to also output debug output.

What I'm asking for is a way to still have this output behind a log-level flag. You can still write it to stderr if you'd like, it's just not as useful when it's a status message.

While the above vagrant thing happens all the time, from time to time I get an email from my boss - who is by no means non-technical - as to why our deploy is erroring. Turns out npm likes to output status messages to stderr as well, resulting in hundreds of lines like this:

It's not an error, npm is running fine, it's just letting us know that certain packages we depend on could use cleanup. And rather than place that behind a flag that I can control - we write deploy logs to files and selectively write to stdout depending upon verbosity of the deploy - it decided to just write to stderr. The deploy didn't fail - because of course i checked the exit code of the command - but it seems like there was an error to the end-user.

I guess what I'm saying is that writing these status messages to stderr by default without some notion of log-levels just isn't friendly for developers.

Then use the -q flag, @josegonzalez.

Would that silence actual error output?

I'm not familiar with the logger you are using in composer, but if it supports the standard log-levels, would you all be opposed to me adding a --log-level argument which sorts the messages into different levels?

@josegonzalez the console output is not using a logger

Would you be opposed to a change that uses a logger (probably monolog)?

I don't feel a logger would be the right answer here, as tempting as it
might be. Instead, making more use of the various verbosity levels would
benefit composer more. During my scavenger hunt through the code I found
very little use of these, and more often than not it just checks for
verbose or it doesn't check anything at all, even though there are three
levels available. If anything, I would invest time in improving that. Just
my 2 cents :-)
On Mar 6, 2015 10:10 PM, "Jose Diaz-Gonzalez" notifications@github.com
wrote:

Would you be opposed to a change that uses a logger (probably monolog)?

—
Reply to this email directly or view it on GitHub
#3715 (comment).

Yeah I think what we need is a way to indicate the minimum verbosity level in the write/writeError call, so we can make more use of it without annoying ifs everywhere. That wouldn't solve the whole issue though, we still need a new VERBOSITY_ERROR level IMO that's used for actual error messages. It would be the same as verbosity normal (i.e. show always by default), but with this -Q flag or so we could suppress NORMAL but not ERROR, so we get quiet-except-errors or full-shut-up mode :)

Would it be an option to consider any stderr output without a verbosity
flag to always be an error as opposed to stderr output with a verbosity
flag being informational?
On Mar 7, 2015 7:50 AM, "Jordi Boggiano" notifications@github.com wrote:

Yeah I think what we need is a way to indicate the minimum verbosity level
in the write/writeError call, so we can make more use of it without
annoying ifs everywhere. That wouldn't solve the whole issue though, we
still need a new VERBOSITY_ERROR level IMO that's used for actual error
messages. It would be the same as verbosity normal (i.e. show always by
default), but with this -Q flag or so we could suppress NORMAL but not
ERROR, so we get quiet-except-errors or full-shut-up mode :)

—
Reply to this email directly or view it on GitHub
#3715 (comment).