Re: .profile not being src'd at login on uptodate buster
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.
Reply to: