From mboxrd@z Thu Jan 1 00:00:00 1970 From: x Subject: Re: seekable pipes Date: Tue, 21 Jun 2005 15:41:45 -0700 (PDT) Message-ID: <20050621224145.37819.qmail@web30201.mail.mud.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: fsdevel , Linux-userfs , x Return-path: Received: from web30201.mail.mud.yahoo.com ([68.142.200.84]:20658 "HELO web30201.mail.mud.yahoo.com") by vger.kernel.org with SMTP id S262428AbVFUWl6 (ORCPT ); Tue, 21 Jun 2005 18:41:58 -0400 To: Bryan Henderson , frederik@ofb.net In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Actually, I don't see how it matters either way. Named pipes get set up in pretty much the same way as anonymous ones, except the two processes don't have to be related. But the point is that the seekability of the pipe is essentially a property of the reader of that pipe, not the writer -- thus one can imagine being able to do: $ command_that_understands_seekable_pipes | command_that_requires_seekable_stdin without the second command or the shell having to know anything in particular about the seekable pipes API. One can also imagine a special command, seekcat, which takes unseekable stdin, and buffers it to create a seekable stdout. --- Bryan Henderson wrote: > When you first described the concept, I was thinking > of named pipes, which > someone would separately create. It's still good > for that. For > shell-made pipes > (| and <>()), though, I agree -- the shell has to > change. I don't see any > other reasonable way. > > -- > Bryan Henderson IBM Almaden > Research Center > San Jose CA Filesystems > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com