STDERR instead of STDOUT for default drush output

[lukey78]

Hi there,

is there any reason why Drush by default outputs all messages to STDERR even if no errors happen, like when I do a simple cache-clear?

We usually use Drush in our deploy scripts with Capistrano, and all the drush output is displayed in red color because of that. Of course we could change the deploy recipes to always redirect STDERR to STDOUT, but... why?

Thanks for clearing this up.

[jpSimkins]

+1

[weitzman]

Only the output format system prints to STDOUT. All the other junk is
segregated to STDERR. This change happenned 5 years ago. See
https://www.drupal.org/node/639204. You can try to use --quiet to reduce
the noise, if you want.

On Thu, Jul 3, 2014 at 11:37 AM, Jeremy Simkins [email protected]
wrote:

+1

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

[lukey78]

Mmh, thanks. "dww" commented it the right way 5 years ago:

Regardless of -v or -d, errors belong in stderr. That's how UNIX has worked for decades, for good
reason. ;) Otherwise, you can't pipe things into each other or the payload gets mixed in with the
errors/warnings.

It seems the change happened to all the debugging output regardless if it's an error or not. It's rather odd that Drush prints a [success] message to STDERR.

In drush.inc the log entry is parsed and several "message levels" are defined: warning, cancel, failed, error, ok, completed, success, status, notice, message and info.

I think only "warning", "cancel", "failed" and "error" should go to STDERR, everyting else belongs to STDOUT.

Any thoughts why it should stay the wrong way?

[tizzo]

[[[[I disagree, 'ok' or 'success' are not errors but they are just status outputs not generally the data you actually requested. Whatever comes through drush_log should go to stderr (e.g. Command dispatch complete) while the data you request (e.g. a list of enabled modules) should go to stdout. If you want to pipe stderr and stdout together you can easily do that with standard bash tricks like 2>&1.

[weitzman]

By Design

[helderco]

I don't get it. How do I get notified of errors during cron? It seems my option is to suppress all output, including the useful errors. I can't suppress "[notice] WD cron: Cron run completed." with --quiet anymore, and it's going to stderr so I can't just trash stdout.

[greggles]

I used to think STDERR was for all errors - it's right there in the name, even!

I later noticed many commands that log most information to STDERR while sending the program output to STDOUT. Reading about STDERR on wikipedia:

Standard error is another output stream typically used by programs to output error messages or diagnostics. It is a stream independent of standard output and can be redirected separately. This solves the semipredicate problem, allowing output and errors to be distinguished, and is analogous to a function returning a pair of values – see Semipredicate problem: Multivalued return.

In modern drush, if you want to send something to STDOUT you can do it a few ways, but a solid method is:

$this->output()->writeln('foo');

[ElijahLynn]

Thanks for this thread! Just spent an hour trying to figure out why my pipe to grep test command to detect new PHP ERRORs are introduced in CI wasn't working and finally realized all drush output is sent to STDERR, this thread was really useful in confirming this after we realized the issue!

e.g. drush watchdog:show --type=php --severity=warning | grep "No log messages"

I expected it to return a 0 but since the return value of No log messages available. from drush is going to STDERR, I was getting an rc of 1.

This works but is/was confusing to me as I had no reason to suspect this would go to STDERR: drush watchdog:show --type=php --severity=warning 2>&1 | grep "No log messages"