Why does the output of some Linux programs go to neither STDOUT nor STDERR?

Solution 1:

This question is addressed in BashFAQ/032. In your example, you would:

{ time sleep 1; } 2> /dev/null

The reason why

time sleep 1 2>/dev/null

doesn't behave how you're expecting is because with that syntax, you'll want to time the command sleep 1 2>/dev/null (yes, the command sleep 1 with stderr redirected to /dev/null). The builtin time works that way so as to make this actually possible.

The bash builtin can actually do this because... well, it's a builtin. Such a behavior would be impossible with the external command time usually located in /usr/bin. Indeed:

$ /usr/bin/time sleep 1 2>/dev/null
$

Now, the answer to your question

Why does the output of some linux programs go to neither STDOUT nor STDERR?

is: it does, the output goes to stdout or stderr.

Hope this helps!

Solution 2:

Your particular question about time builtin has been answered, but there are some commands that don't write either to stdout or to stderr. A classic example is the Unix command crypt. crypt with no arguments encrypts standard input stdin and writes it to standard output stdout. It prompts the user for a password using getpass(), which by defaults outputs a prompt to /dev/tty. /dev/tty is the current terminal device. Writing to /dev/tty has the effect of writing to the current terminal (if there is one, see isatty()).

The reason crypt can't write to stdout is because it writes encrypted output to stdout. Also, it's better to prompt to /dev/tty instead of writing to stderr so that if a user redirects stdout and stderr, the prompt is still seen. (For the same reason, crypt can't read the password from stdin, since it's being used to read the data to encrypt.)