Re: [PATCH v2] test-skeleton: redirect stderr to stdout

[Pedro Alves <palves at redhat dot com>]

On 06/17/2016 03:47 PM, Mike Frysinger wrote:
> On 17 Jun 2016 12:12, Pedro Alves wrote:
>> On 06/17/2016 06:29 AM, Mike Frysinger wrote:
>>
>>> +  /* Bind stderr to stdout so that tests don't have to worry about which
>>> +     one to use, and whether funcs they use (e.g. assert) will go to the
>>> +     wrong place.  */
>>> +  fclose (stderr);
>>> +  if (dup2 (STDOUT_FILENO, STDERR_FILENO) == -1)
>>> +    {
>>> +      printf ("binding stderr to stdout failed: %m\n");
>>> +      exit (1);
>>> +    }
>>> +  stderr = fdopen (STDERR_FILENO, "w");
>>> +  /* Since stderr always starts out unbuffered, recreate that here.  */
>>> +  setbuf (stderr, NULL);
>>
>> Why do you need to fclose/fdopen stderr at all?
>> Just the "dup2 (STDOUT_FILENO, STDERR_FILENO)" should be enough.
> 
> we discussed it here where i asked for docs:
> https://sourceware.org/ml/libc-alpha/2016-06/msg00636.html

I don't have a reference handy.  However, this is how everyone
does it.  If it doesn't work, then a ton of programs (and shells) out
there are broken, including all that do:

dup2(..., 0);
dup2(..., 1);
dup2(..., 2);
execvp (...);
perror ("exec failed"); // writes to stderr.
exit(1);


Even the glibc manual shows perror used like that:

 https://www.gnu.org/software/libc/manual/html_node/Launching-Jobs.html#Launching-Jobs


If you may have output pending in stdio's buffers, then call
fflush before the dup2.  But then again stderr is unbuffered
by default, and, if you do already have output pending,
then you're doing this redirection too late, anyway.

> 
>> Note that that's what
>>
>>  http://pubs.opengroup.org/onlinepubs/9699919799/functions/dup.html
>>
>> suggests in its example section:
>>
>> ~~~~~~~~~~~~~~~~~~~~~
>>  Redirecting Error Messages
>>
>>  The following example redirects messages from stderr to stdout.
>>
>>  #include <unistd.h>
>>  ...
>>  dup2(1, 2);
>>  ...
>> ~~~~~~~~~~~~~~~~~~~~~
> 
> that only guarantees the fd level.  where do we guarantee the stdio level ?

The mention of "stderr to stdout" is clearly talking about the
stdio objects.  If to redirect "stderr to stdout" you would need
some further manipulation at the stdio level, then it seems obvious to me
that that example would show what else to do to the stdout/stderr objects.

Thanks,
Pedro Alves