What's up with our stdout?

[Andrew Reilly]

On Sat, Jun 24, 2006 at 06:31:10PM -0700, Steve Kargl wrote:
> On Sun, Jun 25, 2006 at 11:17:46AM +1000, Andrew Reilly wrote:
> >
> > The question is: what's wrong with our shell or stdout that a
> > program (nbcat in this case) can't fcntl-lock the file opened
> > for output?  Is this related to the /dev/stdout@ -> fd/1 files
> > that we have?  Seems like a shortcoming to me...
> > 
> 
> Have you reviewed the nbcat source code to determine
> what wrong assumptions it is making about stdout and/or
> fcntl?

What's to assume?  The shell should make file descriptor 1 be
the output file, opened for writing or append, depending on
whether you used > or >> on the command line, no?

NetBSD's cat.c just says:

        if (lflag) {
                stdout_lock.l_len = 0;
                stdout_lock.l_start = 0;
                stdout_lock.l_type = F_WRLCK;
                stdout_lock.l_whence = SEEK_SET;
                if (fcntl(STDOUT_FILENO, F_SETLKW, &stdout_lock) == -1)
                        err(EXIT_FAILURE, "stdout");
        }

Looks OK to me.

The file opened for stdout is definitely a normal file.  F_SETLKW
should succeed or wait in this case, IMO.

Our stdout(4) doesn't say anything that looks ominous, but I
admit to being far from a guru on the issue.  I don't even
understand how those /dev/fd devices interact with the system,
or why they're there (other than as a way to fake a "-" file
argument to programs that don't normally have one).  I don't see
how they're relevant in this case though.

Cheers,

-- 
Andrew