On Tue, Jul 24, 2012 at 7:51 PM, Nadav Har'El <[email protected]>wrote:
> On Tue, Jul 24, 2012, Oleg Goldshmidt wrote about "Re: how to redirect in > bash+crontab": > > Isn't it the same as redirecting stderr to a real file and finding out > that > > you don't have permissions to write to it? > > No, this cannot happen. write(2) cannot fail because of permission > problems, only the open(2) can. But you cannot write(2) before you open(2), can you? Once a process has a file descriptor > it can write it even if it could never open the original file itself. > Which s true for file descriptors (e.g., dup()), but to redirect to a file you do need to open(2) the file, methinks. > > > But I think it's important that this caveat is documented in proc(5), > > > > And in bash(1), as I pointed out in my reply to Amos. > > Holy shit! > > I just noticed that bash(1) claims that ">/dev/stderr" doesn't actually > open a file called /dev/stderr - but just does dup(2). Either this is > not true, or you simply weren't using Bash - perhaps your crontab uses > dash or something else. > 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). 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. I would be curious to know how recent versions of SuSE/debian/ubuntu/*BSD/Mac OS X/whatever implement /dev/stderr. -- Oleg Goldshmidt | [email protected] <[email protected]>
_______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
