Paul Mylchreest <mylchreest(_at_)sympatico(_dot_)ca> writes:
You could be right. It solves the problem. However, I thought:
fetchmail 2>&1 >/dev/null
(redirect stderr to stdout and pipe stdout to null)
fetchmail 2> /dev/null 1>/dev/null
No, the order is relevant. On the left hand side of the redirection, you
find the FD that fetchmail sees, on the right hand side, you see which
"old" descriptor this maps to.
The first copies your shell's stdout file descriptor as fetchmail's
stderr, and then assigns fetchmail's stdout to NULL. It's difficult to
understand, and it's some obscure Unix magic, don't worry.
If you write >/dev/null 2>&1, then things work as you expect: first, the
stdout is mapped to /dev/null, then, this /dev/null is copied to
fetchmail's stderr -> both then point to /dev/null.