On Thu, Apr 08, 2021 at 11:14:48AM +0100, Tixy wrote: > I believe ">/dev/stderr" is not Posix standard and knowing the correct > standard way of doing this could be beneficial.
That's correct -- it's not portable. On systems where /dev/stderr actually exists (such as Debian GNU/Linux), according to the man page, bash will actually open /dev/stderr and the semantics will be those of whatever the underlying operating system implements. Testing for confirmation: unicorn:~$ strace -eopen,openat bash -c 'echo hi >/dev/stderr' 2>&1 | tail -3 openat(AT_FDCWD, "/dev/stderr", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 hi +++ exited with 0 +++ A redirection to /dev/stderr on systems where a real /dev/stderr does NOT exist is handled internally by bash, and is treated similarly to >&2. (I actually wish bash would do this on ALL systems for consistency, but alas.) Any other use of /dev/stderr (not a redirection) relies on the operating system's actual /dev/stderr node, which may not exist on commercial Unix systems, and whose semantics are different across different systems where it does exist. Why is that an issue? On some systems, /dev/stderr is a symlink to something like /dev/fd/2 which means you get the file descriptor duplication semantics that you want. On other systems, it's a symlink directly to some device node, and opening it gives you a second, independent file descriptor pointing to that device. Writes to the two file descriptors are therefore NOT synchronized, the way they would be if you had used >&2. And of course, if the shell reading the script is NOT bash, then you would have to consult the documentation for whichever shell it is. In many cases, you'll be relying on the operating system's /dev/stderr node. tl;dr: Just use >&2.