1
  $ tty
  /dev/tty0

On

      $cat 

in user-space, cat process waits on it's stdin to receive input from /dev/tty0 file.

On listing non-existent file fff,

  ls /fff > file1
   ls cannot find file :file1 Access denied

Despite redirection of stdout to file1 instead of /dev/tty0, the error about, file does not exist, will display on /dev/tty0 through stderr file descriptor.


Question:

If stderr writes to /dev/tty0 similar to stdout, what is the purpose of stderr?

What was the idea behind, UNIX/Linux maintaining one more file descriptor stderr for writing error to /dev/tty0 ?

overexchange
  • 1,536

2 Answers2

3

We need STDERR (file descriptor 2) to separate the output stream (STDOUT, file descriptor 1) from the error stream.

Without the separation, you can not distinguish the valid outputs from errors.

As you can see in your case, both streams are being attached to the terminal, and you can easily distinguish or operate on them (dup(2) et al.) by simple file descriptor operations from userspace.

Just an an example, to send STDOUT to a file and STDERR to a different file:

my_command >stdout.log 2>stderr.log
heemayl
  • 56,300
-3

stdoout is expected to be opened in a write-only state for every unix process from launch, stdin as read-only (as i think), and stderr as non-blocking read/write deploying - at maximum - a line out-buffer.

stderr is primarily for getting output to a consumer immediately, and is heavily relied upon in terminal user interface applications; have a look at more.

  • 1
    Both Read/write from stderr? – overexchange May 07 '17 at 06:07
  • According to the manpage on Arch Linux, stderr is unbuffered, while stdout is line-buffered. Further, I am almost completely certain that there is no system where by default stderr is RW but stdout is write-only. I'm open to learning otherwise though — any chance you could cite some sources on this? – Fox May 07 '17 at 17:04