From owner-freebsd-arch@FreeBSD.ORG Sun Jun 25 02:01:57 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE7A616A492 for ; Sun, 25 Jun 2006 02:01:57 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta04sl.mx.bigpond.com (omta04sl.mx.bigpond.com [144.140.93.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1906D43D60 for ; Sun, 25 Jun 2006 02:01:56 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.7.22]) by omta04sl.mx.bigpond.com with ESMTP id <20060625020155.VXSP7229.omta04sl.mx.bigpond.com@areilly.bpc-users.org> for ; Sun, 25 Jun 2006 02:01:55 +0000 Received: (qmail 81707 invoked from network); 25 Jun 2006 02:01:58 -0000 Received: from gurney.reilly.home (HELO areilly.bpc-users.org) (10.0.0.1) by localhost with SMTP; 25 Jun 2006 02:01:58 -0000 Received: (qmail 89402 invoked by uid 501); 25 Jun 2006 02:01:54 -0000 Date: Sun, 25 Jun 2006 12:01:54 +1000 From: Andrew Reilly To: Steve Kargl Message-ID: <20060625020154.GA89358@gurney.reilly.home> References: <20060625011746.GC81052@duncan.reilly.home> <20060625013110.GA62237@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060625013110.GA62237@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arch@freebsd.org Subject: Re: What's up with our stdout? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2006 02:01:57 -0000 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