Re: seekable pipes

[Jeff Anderson-Lee <jonah@eecs.berkeley.edu>]

x wrote:

>>In
>>the anonymous case 
>>(more precisely, the case of the anonymous pipe
>>generated and deployed by 
>>a seekable-pipe-agnostic program such as Bash), you
>>can't make sure the 
>>guy who makes the pipe seekable does so before the
>>guy who needs it to be 
>>seekable notices that it's not.
>>    
>>
>
>OK. This can of course be circumvented by doing
>$ command_that_understands_seekable_pipes |
>(command_that_checks_stdin;
>command_that_requires_seekable_stdin)
>
>But I see how this is something best done in the
>shell.
>
>In any case, you'd need some kind of ioctl to ask the
>kernel to wait for the other end of the pipe to become
>seekable (or be written or closed).
>
To paraphrase: "the wonderful things about shells is that there are so 
many to choose from".  However one doesn't need to reinvent (or retool) 
the entire wheel/shell industry to get started.  What about just 
starting with a simple "one line" seek-in command that can be called in 
such cases as required?  If it becomes used enough, shell developers 
will eventually absorb it as they did with "test" and "echo", etc.

The syntax could be something like:

$ command_to_manage_seekable_stdout | seek-in [--] 
command_to_use_seekable_stdin

Where seek-in pauses briefly to allow the first command to convert the 
pipe to seekable mode before execing its arguments.  The shell variable 
parsing and other redirection is inherited from (managed by) the 
surrounding shell.  An optional time-out might prevent an infinite wait 
if the first command never converted the pipe.

Jeff Anderson-Lee