Date: Sun, 25 Jun 2006 12:01:54 +1000 From: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-arch@freebsd.org Subject: Re: What's up with our stdout? Message-ID: <20060625020154.GA89358@gurney.reilly.home> In-Reply-To: <20060625013110.GA62237@troutmask.apl.washington.edu> References: <20060625011746.GC81052@duncan.reilly.home> <20060625013110.GA62237@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060625020154.GA89358>