<div dir="ltr"><font face="georgia,serif"><br></font><br><div class="gmail_quote">On Tue, Jul 24, 2012 at 7:51 PM, Nadav Har'El <span dir="ltr"><<a href="mailto:nyh@math.technion.ac.il" target="_blank">nyh@math.technion.ac.il</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jul 24, 2012, Oleg Goldshmidt wrote about "Re: how to redirect in bash+crontab":<br>
<div class="im">> Isn't it the same as redirecting stderr to a real file and finding out that<br>
> you don't have permissions to write to it?<br>
<br>
</div>No, this cannot happen. write(2) cannot fail because of permission<br>
problems, only the open(2) can.</blockquote><div><br>But you cannot write(2) before you open(2), can you?<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Once a process has a file descriptor<br>
it can write it even if it could never open the original file itself.<br></blockquote><div><br>Which s true for file descriptors (e.g., dup()), but to redirect to a file you do need to open(2) the file, methinks.<br> <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> > But I think it's important that this caveat is documented in proc(5),<br><div class="im">
><br>
> And in bash(1), as I pointed out in my reply to Amos.<br>
<br>
</div>Holy shit!<br>
<br>
I just noticed that bash(1) claims that ">/dev/stderr" doesn't actually<br>
open a file called /dev/stderr - but just does dup(2). Either this is<br>
not true, or you simply weren't using Bash - perhaps your crontab uses<br>
dash or something else.<br></blockquote><div><br>Whatever crontab uses is irrelevant since all there is in crontab is the name of a script that is explicitly #!/bin/bash (and al the scripts that are called are explicitly bash as well).<br>
<br></div>Strictly speaking, "man bash" does not explicitly say it does not open() /dev/stderr (it says it dup()s but does not say this is the only thing it does). Nevertheless I think the documentation's intent is exactly that - no open(), or at least ignoring mode during open(), consistent with the /dev/fd/* behaviour as described by Stevens and everywhere else.<br>
<br>I would be curious to know how recent versions of SuSE/debian/ubuntu/*BSD/Mac OS X/whatever implement /dev/stderr.<br><br></div>-- <br>Oleg Goldshmidt | <a href="mailto:oleg@goldshmidt.org" target="_blank">pub@goldshmidt.org</a><br>
</div>