fileno(stdin) versus STDIN_FILENO and friends

[Chris Johns]

On 13/03/11 8:29 AM, Peter Dufault wrote:
>
> Consider the following, with two commands added to the RTEMS shell, one to print the filenos for stdin, stdout, and stderr and the second to print "Hello world" to the stderr thread after becoming a thread, i.e.:
>
> static void *hello(void *arg)
> {
>      fprintf(stderr, "Hello stderr!\n");
>      return (void *)0;
> }
> static int
> hello_stderr(int argc, char **argv)
> {
>      pthread_t t;
>      pthread_create(&t, 0, hello, 0);
>      return 0;
> }
>
> When run from the console the output is:
>
> [/] # filenos
> fileno(stdin),  STDIN_FILENO:  0 0
> fileno(stdout), STDOUT_FILENO: 1 1
> fileno(stderr), STDERR_FILENO: 2 2
> [/] # hello
> [/] # Hello stderr!
>
> When run from telnet the output is:
>
> [/] # filenos
> fileno(stdin),  STDIN_FILENO:  7 0
> fileno(stdout), STDOUT_FILENO: 8 1
> fileno(stderr), STDERR_FILENO: 9 2
> [/] # hello
> [/] #
>
> And you see this on the console:
>
> syslog: telnetd: accepted connection from 192.168.240.6 on /dev/pty0
> Hello stderr!
>

This does not seem to follow the intended purpose of telnet for RTEMS.

> So, stdin, stdout, and stderr are redirected per-thread, but descendants of the threads revert to 0, 1, and 2.

> Is this in described by any standard?

I suspect not.

>  If not, and we're just dealing with undefined behavior, is there any reason not to make it optional that descendants of a thread inherit the file descriptors for stdin, stdout, and stderr from the parent thread?  I'd find that behavior a lot more convenient, for example, threads started from telnet where the stderr went to the telnet window would still go to the telnet window.  I consider it important to route stdout and stderr to reasonable places, for example, an error log in a window some place, and I'm trying to setup an environment for less experienced users where things work well.

I think it is reasonable to make this change. The whole shell and telnet 
on RTEMS is an application trick to make the RTEMS "process" appear 
multi-user and process based. We should attempt to make this emulation 
appear as standard.

Chris