----- 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.
-Steve
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
