Sounds great. You guys please have at it!
Andrei
Steve Schveighoffer wrote:
I can help you with some aspects of it, I revamped tangos' Process object a
while back.
Some things about my experience with Tango's Process:
1. I included a similar "redirect flags" option for the process, with the added
ability to redirect stdout to stderr and vice versa.
2. About the searchPath flag -- Windows' function to create a process already
takes into account the PATH variable, so I'm guessing that flag will be a noop
on Windows? Also, execlp and execvp already take into account the PATH. I
can't imagine you would need to build your own PATH parsing/searching method,
or to run a command without taking the PATH into account (you can do this
anyways by prepending a './'). My advice is to simply use one of those
versions of exec, and get rid of the searchPath flag.
3. Tango's Process object included a means to specify the environment for the
child process (a useful feature). A simple argument with a string[string] for
the environment variables would be useful.
4. For Windows, you do not pass in the command as an array of parameters, you
pass it in as one string. The parsing required for doing so is extremely
convoluted and I only could figure it out by trial and error (documentation was
incomplete). I can help you with that.
5. Some version that parses a command line would be useful. For example, it would be
nice to be able to simply do spawn("ls -l");
6. I think your method of getting the stdout/stderr/stdin handles is a bad
idea. One can see someone not simply storing the stdout/stderr/stdin
properties in an external variable and using them later, but rather always
accessing the property to work with it. This means you create a new FILE* and
a new File object for each access. I think you should store the File object
directly in the Pid struct, and simply refer to it later.
7. Windows has an additional flag to specify that no console should be created.
This is very essential for things like plugins (where you don't want a black
console box to pop up while running a child process). The way I handled this
in Tango is to add a gui flag which was a noop in Linux.
That's all I can think of right now. I agree that std.process is very lacking,
it is good someone is working on this.
-Steve
----- Original Message ----
From: Andrei Alexandrescu <[email protected]>
To: Discuss the phobos library for D <[email protected]>
Sent: Thu, March 4, 2010 8:18:50 AM
Subject: Re: [phobos] Suggestions for std.process
Looks good to me. If everybody else agrees, I'd be glad to extend you an offer
for write access to Phobos so you can commit the changes yourself.
Andrei
Lars Tandle Kyllingstad wrote:
Hi,
Recently, I found myself in need of the functionality that is (or should have
been) in std.process, but unfortunately I found it lacking in many respects.
Assuming that improving it currently isn't at the top of the to-do list for
Phobos, I decided not to wait, and rather to write my own version. If you want
you can check it out here:
Code: http://github.com/kyllingstad/ltk/blob/master/ltk/process.d
Docs: http://kyllingen.net/code/ltk/doc/process.html
I don't know if any of it is usable for Phobos, but if it is, I'd be happy to
contribute.
I've tried to write it in the style of std.concurrency, with a function
spawnProcess() that returns a Pid struct. Currently it is for POSIX only, since
I have no experience at all with the Windows API.
-Lars
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
