Steve Schveighoffer wrote:
----- Original Message ----
From: Lars Tandle Kyllingstad <[email protected]>
Steve Schveighoffer wrote:
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?
That sounds like a good idea. Hm... I read the std.stream code, and I wasn't
aware that Phobos used its own buffering layer in place of C's for everything
but the standard handles. That is good news! However, you are still using
FILE * in your code, you should get rid of that (I don't even know where the
File.wrapFile function is).
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.
Hm... that is annoying. Now that I look at Tango, it actually uses execve, and
does the path parsing (only on Linux/Mac/BSD however). As you say, it should
work the same on both Windows and POSIX, so I think that path search should be
implicit.
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();
Sounds good.
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?
What I mean is, having a method that parses the command line according to
simple sane rules and calls the array-style version. I don't suggest simply
passing the command to Windows, as the parsing and quote escaping is so
ridiculous, nobody should have to deal with it. Wait until you see it :)
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.
As long as we agree on the interface, I can write the Windows version. I am
not the original author of Tango's Process class, that was Reagan Heath, and
then Juan Comellas. I took over because I needed some functionality that
wasn't there, and I found some bugs, and Juan had stopped maintaining it.
Therefore, I can't really give you full permission to copy Tango's Process
class.
But I did write the Windows quote parsing part of it, so I have no problems
copying that over. The rest is pretty straightforward code that can easily be
rewritten from scratch.
That sounds like a great plan, and will most likely by far be the
fastest way to get it up and running on both systems. I'll keep working
on the POSIX stuff, implementing and fixing the things we have
discussed, and try to work the interface into something we can all agree
is good.
I would also like some feedback on how well you guys think the interface
will fit with the new concurrency model. The idea was, as I said
before, to write it in the same style, and when the time comes it should
(API-wise) be a simple, non-breaking change to just add a MessageBox
to the Pid struct.
-Lars
--
Lars Tandle Kyllingstad
@: [email protected]
#: 40233221
w: http://www.kyllingen.net
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
