<div dir="ltr"><font face="georgia,serif"><br></font><br><div class="gmail_quote">On Tue, Jul 24, 2012 at 4:06 PM, Amos Shapira <span dir="ltr"><<a href="mailto:amos.shapira@gmail.com" target="_blank">amos.shapira@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">For the platforms which use a pipe for /dev/stderr try running fuser to see what else has it open. I suspect it would be something like a "mail" process initiated by cron.<br>
<br>In general, /dev/stderr is not a standard, not portable and IMHO shouldn't be relied on.<br>
<br>The shell does exactly what is expected - the "special case" you ask for is the &2 syntax and /dev/stderr is a hack to let you treat stderr as a regular file.<br></div></blockquote><div><br>Well, I know of course that /dev/stderr is bash-specific and is not (necessarily) portable to other shells. I did not care about that kind of portability. The scripts are explicitly #!/bin/bash. In bash, redirecting to /dev/stderr is well documented, and in fact "man bash" says<br>
<br> Bash handles several filenames specially when they are used in redirections, as described in the following table:<br> <...><br> /dev/stderr<br> File descriptor 2 is duplicated.<br>
<br>This is, in fact, not what happens, since, as I mentioned, there is a call to open(2) before dup2(2) and permissions are checked at that stage (">&2" corresponds more closely to the above since it does dup2(2) directly). I still suspect there is a bug somewhere because the process should be able to write to its stderr even under cron (which is supposed to send whatever was written to stderr by mail). <br>
<br></div></div>-- <br>Oleg Goldshmidt | <a href="mailto:oleg@goldshmidt.org" target="_blank">oleg@goldshmidt.org</a><br>
</div>