[phobos] Removing std.stdio.File.popen()
andrei at erdani.com
Tue Aug 17 20:03:34 PDT 2010
I understand that, and the motivation has been thoroughly explained in
the Unix lore. My question is, why define a separate type? Wouldn't
creating a file and calling setbuf(null, 0) suffice?
On 08/17/2010 01:59 AM, Lars Tandle Kyllingstad wrote:
> Basically because you want to know what you're piping to another
> process. Say you read a file up to some point, and want to pass the
> rest of it through a pipe. That won't work if you use File, because you
> don't know what has already been buffered, and what's left in the
> I was originally using File, but after Steve pointed out the problem
> above we decided to add an UnbufferedFile type. Hopefully, it will find
> other uses as well -- perhaps, at some point, we can even build a new
> buffered File on top of it.
> The current API for UnbufferedFile is here, if anyone is wondering:
> On Mon, 2010-08-16 at 12:20 -0500, Andrei Alexandrescu wrote:
>> I also like ltk process quite a bit. One q - why the need for a special
>> type UnbufferedFile?
>> David Simcha wrote:
>>> This looks terrific. I've always found the old std.process to be way
>>> underpowered, especially on Windows. Does your statement about
>>> cross-platformness imply that Windows will eventually be supported, too?
>>> On Mon, Aug 16, 2010 at 9:20 AM, Lars Tandle Kyllingstad
>>> <lars at kyllingen.net<mailto:lars at kyllingen.net>> wrote:
>>> On Mon, 2010-08-16 at 09:04 -0400, Adam Ruppe wrote:
>>> > I actually use it (which is why I duplicated your bug), but am OK
>>> > removing it, since it is easy enough to get at anyway. For a while, I
>>> > did a separate extern(C) for pclose anyway!
>>> > However, I don't think something being POSIX only is a good reason to
>>> > remove something. D should take advantages of whatever platform it is
>>> > on. Portability is good when you can have it, but it shouldn't be a
>>> > function killer alone.
>>> Two comments:
>>> 1. I disagree with you. :) I think that Phobos' user-visible interface
>>> should be completely platform agnostic. Code that depends only on
>>> Phobos should compile and run on any platform.
>>> 2. Steve and I have been working on a new version of std.process, which
>>> will at some point, hopefully, obviate the need for popen(). See
>>> pipeProcess() here:
>>> The POSIX implementation is more or less complete, but its inclusion in
>>> Phobos is currently being blocked by bug 3979. Also, Steve has run into
>>> some very tricky issues with pipes on Windows, fundamentally caused by
>>> D's dependence on the DMC runtime. I don't know how (or if) that is
>>> working out.
>>> phobos mailing list
>>> phobos at puremagic.com<mailto:phobos at puremagic.com>
>>> phobos mailing list
>>> phobos at puremagic.com
>> phobos mailing list
>> phobos at puremagic.com
> phobos mailing list
> phobos at puremagic.com
More information about the phobos