Is It Possible That Linux File Descriptor 0 1 2 Not for Stdin, Stdout and Stderr

Is it possible that linux file descriptor 0 1 2 not for stdin, stdout and stderr?

At the file descriptor level, stdin is defined to be file descriptor 0, stdout is defined to be file descriptor 1; and stderr is defined to be file descriptor 2. See this.

Even if your program -or the shell- changes (e.g. redirect with dup2(2)) what is file descriptor 0, it always stays stdin (since by definition STDIN_FILENO is 0).

^{So of course stdin could be a pipe or a socket or a file (not a terminal). You could test with isatty(3) if it is a tty, and/or use fstat(2) to get status information on it.}

Syscalls like open(2) or pipe(2) or socket(2) may give e.g. STDIN_FILENO (i.e. 0) if that file descriptor is free (e.g. because it has been close(2)-d before). But when that occurs, it is still stdin by definition.

Of course, in stdio(3), the FILE stream stdin is a bit more complex. Your program could fclose(3), freopen(3), fdopen(3) ...

^{Probably the kernel sets stdin, stdout, and stderr file descriptors to the console when magically starting /sbin/init as the first process.}

In linux, stdin, stdout, stderr means open file descriptor?

Here is a small C program fd.c that uses stdout and stderr to print a message to the console.

#include <stdio.h>

int main(int argc, char*argv[])
{
    fprintf(stdout,"message for stdout\n");
    /* fflush(stdout); */
    fprintf(stderr,"message for stderr\n");
    /* fflush(stderr); */

    return 0;
}

To compile: gcc -o fd fd.c

Open a terminal and test run:

./fd
./fd > /tmp/output.log
./fd > /tmp/stdout.log 2>/tmp/stderr.log
./fd > /tmp/all.log 2>&1

Examine each output file. If they look out of sequence, uncomment the fflush statements.

Nothing happens to their relations, they remain as they are as before. The 0,1,2 descriptors are always open by default.

Are stdin and stdout actually the same file?

When the input comes from the console, and the output goes to the console, then all three indeed happen to refer to the same file. (But the console device has quite different implementations for reading and writing.)

Anyway, you should use stdin/stdout/stderr only for their intended purpose; otherwise, redirections like the following would not work:

<inputfile myprogram >outputfile

(Here, stdin and stdout refer to two different files, and stderr refers to the console.)

Strange behavior performing library functions on STDOUT and STDIN's file descriptors

Let's start by reviewing some of the key concepts involved:

• File description

  In the operating system kernel, each file, pipe endpoint, socket endpoint, open device node, and so on, has a file description. The kernel uses these to keep track of the position in the file, the flags (read, write, append, close-on-exec), record locks, and so on.

  The file descriptions are internal to the kernel, and do not belong to any process in particular (in typical implementations).
   

• File descriptor

  From the process viewpoint, file descriptors are integers that identify open files, pipes, sockets, FIFOs, or devices.

  The operating system kernel keeps a table of descriptors for each process. The file descriptor used by the process is simply an index to this table.

  The entries to in the file descriptor table refer to a kernel file description.

Whenever a process uses dup() or dup2() to duplicate a file descriptor, the kernel only duplicates the entry in the file descriptor table for that process; it does not duplicate the file description it keeps to itself.

When a process forks, the child process gets its own file descriptor table, but the entries still point to the exact same kernel file descriptions. (This is essentially a shallow copy, will all file descriptor table entries being references to file descriptions. The references are copied; the referred to targets remain the same.)

When a process sends a file descriptor to another process via an Unix Domain socket ancillary message, the kernel actually allocates a new descriptor on the receiver, and copies the file description the transferred descriptor refers to.

It all works very well, although it is a bit confusing that "file descriptor" and "file description" are so similar.

What does all that have to do with the effects the OP is seeing?

Whenever new processes are created, it is common to open the target device, pipe, or socket, and dup2() the descriptor to standard input, standard output, and standard error. This leads to all three standard descriptors referring to the same file description, and thus whatever operation is valid using one file descriptor, is valid using the other file descriptors, too.

This is most common when running programs on the console, as then the three descriptors all definitely refer to the same file description; and that file description describes the slave end of a pseudoterminal character device.

Consider the following program, run.c:

#define  _POSIX_C_SOURCE 200809L
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>

static void wrerrp(const char *p, const char *q)
{
    while (p < q) {
        ssize_t  n = write(STDERR_FILENO, p, (size_t)(q - p));
        if (n > 0)
            p += n;
        else
            return;
    }
}

static inline void wrerr(const char *s)
{
    if (s)
        wrerrp(s, s + strlen(s));
}

int main(int argc, char *argv[])
{
    int fd;

    if (argc < 3) {
        wrerr("\nUsage: ");
        wrerr(argv[0]);
        wrerr(" FILE-OR-DEVICE COMMAND [ ARGS ... ]\n\n");
        return 127;
    }

    fd = open(argv[1], O_RDWR | O_CREAT, 0666);
    if (fd == -1) {
        const char *msg = strerror(errno);
        wrerr(argv[1]);
        wrerr(": Cannot open file: ");
        wrerr(msg);
        wrerr(".\n");
        return 127;
    }

    if (dup2(fd, STDIN_FILENO) != STDIN_FILENO ||
        dup2(fd, STDOUT_FILENO) != STDOUT_FILENO) {
        const char *msg = strerror(errno);
        wrerr("Cannot duplicate file descriptors: ");
        wrerr(msg);
        wrerr(".\n");
        return 126;
    }
    if (dup2(fd, STDERR_FILENO) != STDERR_FILENO) {
        /* We might not have standard error anymore.. */
        return 126;
    }

    /* Close fd, since it is no longer needed. */
    if (fd != STDIN_FILENO && fd != STDOUT_FILENO && fd != STDERR_FILENO)
        close(fd);

    /* Execute the command. */
    if (strchr(argv[2], '/'))
        execv(argv[2], argv + 2);  /* Command has /, so it is a path */
    else
        execvp(argv[2], argv + 2); /* command has no /, so it is a filename */

    /* Whoops; failed. But we have no stderr left.. */
    return 125;
}

It takes two or more parameters. The first parameter is a file or device, and the second is the command, with the rest of the parameters supplied to the command. The command is run, with all three standard descriptors redirected to the file or device named in the first parameter. You can compile the above with gcc using e.g.

gcc -Wall -O2 run.c -o run

Let's write a small tester utility, report.c:

#define  _POSIX_C_SOURCE 200809L
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <stdio.h>
#include <errno.h>

int main(int argc, char *argv[])
{
    char    buffer[16] = { "\n" };
    ssize_t result;
    FILE   *out;

    if (argc != 2) {
        fprintf(stderr, "\nUsage: %s FILENAME\n\n", argv[0]);
        return EXIT_FAILURE;
    }

    out = fopen(argv[1], "w");
    if (!out)
        return EXIT_FAILURE;

    result = write(STDIN_FILENO, buffer, 1);
    if (result == -1) {
        const int err = errno;
        fprintf(out, "write(STDIN_FILENO, buffer, 1) = -1, errno = %d (%s).\n", err, strerror(err));
    } else {
        fprintf(out, "write(STDIN_FILENO, buffer, 1) = %zd%s\n", result, (result == 1) ? ", success" : "");
    }

    result = read(STDOUT_FILENO, buffer, 1);
    if (result == -1) {
        const int err = errno;
        fprintf(out, "read(STDOUT_FILENO, buffer, 1) = -1, errno = %d (%s).\n", err, strerror(err));
    } else {
        fprintf(out, "read(STDOUT_FILENO, buffer, 1) = %zd%s\n", result, (result == 1) ? ", success" : "");
    }

    result = read(STDERR_FILENO, buffer, 1);
    if (result == -1) {
        const int err = errno;
        fprintf(out, "read(STDERR_FILENO, buffer, 1) = -1, errno = %d (%s).\n", err, strerror(err));
    } else {
        fprintf(out, "read(STDERR_FILENO, buffer, 1) = %zd%s\n", result, (result == 1) ? ", success" : "");
    }

    if (ferror(out))
        return EXIT_FAILURE;
    if (fclose(out))
        return EXIT_FAILURE;

    return EXIT_SUCCESS;
}

It takes exactly one parameter, a file or device to write to, to report whether writing to standard input, and reading from standard output and error work. (We can normally use $(tty) in Bash and POSIX shells, to refer to the actual terminal device, so that the report is visible on the terminal.) Compile this one using e.g.

gcc -Wall -O2 report.c -o report

Now, we can check some devices:

./run /dev/null    ./report $(tty)
./run /dev/zero    ./report $(tty)
./run /dev/urandom ./report $(tty)

or on whatever we wish. On my machine, when I run this on a file, say

./run some-file ./report $(tty)

writing to standard input, and reading from standard output and standard error all work -- which is as expected, as the file descriptors refer to the same, readable and writable, file description.

The conclusion, after playing with the above, is that there is no strange behaviour here at all. It all behaves exactly as one would expect, if file descriptors as used by processes are simply references to operating system internal file descriptions, and standard input, output, and error descriptors are duplicates of each other.

What are file descriptors, explained in simple terms?

In simple words, when you open a file, the operating system creates an entry to represent that file and store the information about that opened file. So if there are 100 files opened in your OS then there will be 100 entries in OS (somewhere in kernel). These entries are represented by integers like (...100, 101, 102....). This entry number is the file descriptor.
So it is just an integer number that uniquely represents an opened file for the process.
If your process opens 10 files then your Process table will have 10 entries for file descriptors.

Similarly, when you open a network socket, it is also represented by an integer and it is called Socket Descriptor.
I hope you understand.

What is represented by the content of FILE*

What does the value of FILE* represent?

It is a pointer to FILE structure, for glibc its definition is here. Which, among other things, contains the file descriptor. You can get the file descriptor from FILE* using POSIX fileno function.

For more details you may like having a look into Interaction of File Descriptors and Standard I/O Streams.

Confused about stdin, stdout and stderr?

Standard input - this is the file handle that your process reads to get information from you.

Standard output - your process writes conventional output to this file handle.

Standard error - your process writes diagnostic output to this file handle.

That's about as dumbed-down as I can make it :-)

Of course, that's mostly by convention. There's nothing stopping you from writing your diagnostic information to standard output if you wish. You can even close the three file handles totally and open your own files for I/O.

When your process starts, it should already have these handles open and it can just read from and/or write to them.

By default, they're probably connected to your terminal device (e.g., /dev/tty) but shells will allow you to set up connections between these handles and specific files and/or devices (or even pipelines to other processes) before your process starts (some of the manipulations possible are rather clever).

An example being:

my_prog <inputfile 2>errorfile | grep XYZ

which will:

• create a process for my_prog.
• open inputfile as your standard input (file handle 0).
• open errorfile as your standard error (file handle 2).
• create another process for grep.
• attach the standard output of my_prog to the standard input of grep.

---

Re your comment:

When I open these files in /dev folder, how come I never get to see the output of a process running?

It's because they're not normal files. While UNIX presents everything as a file in a file system somewhere, that doesn't make it so at the lowest levels. Most files in the /dev hierarchy are either character or block devices, effectively a device driver. They don't have a size but they do have a major and minor device number.

When you open them, you're connected to the device driver rather than a physical file, and the device driver is smart enough to know that separate processes should be handled separately.

The same is true for the Linux /proc filesystem. Those aren't real files, just tightly controlled gateways to kernel information.

Get file descriptor of stdout c

Your code contains the fragment:

if (argc > 1 && (fd = open(argv[1], 0) == -1))

The result in fd is as if you'd written the comparison inside parentheses:

if (argc > 1 && (fd = (open(argv[1], 0) == -1)))

So the result assigned to fd is correctly 1 because the value returned by open() is indeed -1. You should have parentheses around the assignment:

if (argc > 1 && (fd = open(argv[1], 0)) == -1)

---

Related Topics