Return to Answer

When you log in, stdin, stdout and stderr are connected to the terminal from where you log in. To be more exact, the tty is typcally opened and stdout and stderr are a result from two dup(2) operations on the first file descriptor. This allows to read from stderr in order to get input from the termnal.

As mentioned in the other answer, programs read from stderr in order to get an interactive reply on a question.

Since a user cannot know under which circumstances a program reads from stderr, it is a useless attempt to intentionally write data into stderr from another program.

Note that today programs usually first try to open /dev/tty and use stderr only in case that does not work.

Programs that only read from stderr usually have never been modified since before 1979 and such programs usualy contain constructs like:

int i 1;

that are not accepted by modern C compilers. As a result, it is most unlikely that you today will find a program that never opens /dev/tty but rather reads interactive replies from stderr.

When you log in, stdin, stdout and stderr are connected to the terminal from where you log in. To be more exact, the tty is typcally opened and stdout and stderr are a result from two dup(2) operations on the first file descriptor. This allows to read from stderr in order to get input from the termnal.

As mentioned in the other answer, programs read from stderr in order to get an interactive reply on a question.

Since a user cannot know under which circumstances a program reads from stderr, it is a useless attempt to intentionally write data into stderr from another program.

Note that today programs usually first try to open /dev/tty and use stderr only in case that does not work.

Programs that only read from stderr usually have never been modified since before 1979 and such programs usualy contain constructs like:

int i 1;

or

i =* 2;

that are not accepted by modern C compilers. As a result, it is most unlikely that you today will find a program that never opens /dev/tty but rather reads interactive replies from stderr.

When you log in, stdin, stdout and stderr are connected to the terminal from where you log in. To be more exact, the tty is typcally opened and stdout and stderr are a result from two dup(2) operations on the first file descriptor. This allows to read from stderr in order to get input from the termnal.

As mentioned in the other answer, programs read from stderr in order to get an interactive reply on a question.

Since a user cannot know under which circumstances a program reads from stderr, it is a useless attempt to intentionally write data into stderr from another program.

Note that today programs usually first try to open /dev/tty and use stderr only in case that does not work.

Programs that only read from stderr usually have never been modified since before 1979 and such programs usualy contain constructs like:

i =+ 1;

that are not accepted by modern C compilers. As a result, it is most unlikely that you today will find a program that never opens /dev/tty but rather reads interactive replies from stderr.

When you log in, stdin, stdout and stderr are connected to the terminal from where you log in. To be more exact, the tty is typcally opened and stdout and stderr are a result from two dup(2) operations on the first file descriptor. This allows to read from stderr in order to get input from the termnal.

As mentioned in the other answer, programs read from stderr in order to get an interactive reply on a question.

Since a user cannot know under which circumstances a program reads from stderr, it is a useless attempt to intentionally write data into stderr from another program.

Note that today programs usually first try to open /dev/tty and use stderr only in case that does not work.

Programs that only read from stderr usually have never been modified since before 1979 and such programs usualy contain constructs like:

int i 1;

that are not accepted by modern C compilers. As a result, it is most unlikely that you today will find a program that never opens /dev/tty but rather reads interactive replies from stderr.

When you log in, stdin, stdout and stderr are connected to the terminal from where you log in. To be more exact, the tty is typcally opened and stdout and stderr are a result from two dup(2) operations on the first file descriptor. This allows to read from stderr in order to get input from the termnal.

As mentioned in the other answer, programs read from stderr in order to get an interactive reply on a question.

Since a user cannot know under which circumstances a program reads from stderr, it is a useless attempt to intentionally write data into stderr from another program.

Note that today programs usually first try to open /dev/tty and use stderr only in case that does not work.

Programs that only read from stderr usually have never been modified sincce before 1979 and such programs usualy contain constructs like:

i =+ 1;

that are not accepted by modern C compilers. As a result, it is most unlikely that you today will find a program that never opens /dev/tty but rather reads interactive replies from stderr.

When you log in, stdin, stdout and stderr are connected to the terminal from where you log in. To be more exact, the tty is typcally opened and stdout and stderr are a result from two dup(2) operations on the first file descriptor. This allows to read from stderr in order to get input from the termnal.

As mentioned in the other answer, programs read from stderr in order to get an interactive reply on a question.

Since a user cannot know under which circumstances a program reads from stderr, it is a useless attempt to intentionally write data into stderr from another program.

Note that today programs usually first try to open /dev/tty and use stderr only in case that does not work.

Programs that only read from stderr usually have never been modified since before 1979 and such programs usualy contain constructs like:

i =+ 1;

that are not accepted by modern C compilers. As a result, it is most unlikely that you today will find a program that never opens /dev/tty but rather reads interactive replies from stderr.