Steve Schveighoffer wrote:
I can help you with some aspects of it, I revamped tangos' Process object a
while back.
That would be great!
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.
That's a good idea.
I've actually considered making it even more general, by allowing the
user to provide File objects to replace the standard streams. This
would make it easy to use the output from one process as input to
another, or to pass the contents of a file to a process' input stream.
A simplified example that emulates "foo | bar":
Pid spawnProcess(string executable, File useThisAsInput);
// foo | bar
auto fooPid = spawnProcess("foo");
auto barPid = spawnProcess("bar", foo.stdout);
// baz < myfile.txt
auto bazPid = spawnProcess("baz", File("myfile.txt");
What do you think?
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.
I really can't decide what I think is best. On one hand, having the
function always search the path is convenient, on the other hand, if
your program is going to execute another, there should be as little
chance as possible of it executing the wrong program. (The latter may
be of small concern, though, since one can just include a directory in
the executable name.)
Importantly, though, I think code in Phobos should work in the same way
on both Windows and POSIX, so that more or less settles it for me.
The main reason I wrote my own path-searching mechanism is that the
execvp function not only searches the path, but if that fails it also
tries to run the command through the shell. For some reason I find that
annoying.
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.
That's coming soon, just haven't gotten around to it yet. :) In fact I
have a few ideas regarding environment variables. The getenv() function
has no business being in std.process. Rather, the following functions
should be in std.system:
string getEnv(string varName);
string[string] getEnv();
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.
Awesome!
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");
(That being the default on Windows, right?) I have considered a
spawnShell() function, would that be anything like what you're suggesting?
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.
That's a very good point, and now that you mention it, a rather obvious
mistake. Luckily it's also trivial to implement. Consider it done!
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.
My biggest problem here, which I mentioned in my first e-mail, is that I
have no experience whatsoever with the Windows API. I don't even have a
computer with Windows on it. (Though I may be able to get a Windows
licence through work, I'll have to check that out. Then I'll set up a
virtual machine or something.)
In the event that I'm able to get Windows, we are left with three
options, either of which is fine by me:
1. I spend some time on it, and write it myself, from scratch. This
will take a while.
2. You, as the author of Tango's Process class, if possible, give me
permission to take the Windows part of that code and adapt it to Phobos.
So far I haven't looked at it, due to those dreaded licensing issues.
3. Someone else writes the Windows version. This is the fastest option
by far, but I guess manpower is in short demand.
-Lars
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
--
Lars Tandle Kyllingstad
@: [email protected]
#: 40233221
w: http://www.kyllingen.net
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
