Mike Shaver wrote: > Mark Hammond wrote: > >> My problem would be that SetEnv() wont work as implied. Eg:
> You're the one making the implication. =) True. Although it still seems to have more in common with the program's initial arguments than as a property of the interface itself. eg, Get/SetArgv() would seem somewhat strange to me in the same way Get/SetEnv() does. >> Thus, I believe: >> * nsIProcess should grow a technique for specifying the child >> process's startup environment - probably as a param to a "run" >> method. No need for a "get" at all. > "get" is kinda handy where you don't know what you're inheriting from > the parent. Imagine: I want to add "/opt/mozilla-apps/bin" to the $PATH > before executing another process. get and set. Too much hand-waving. nsICurrentProcess is always the parent process. Whoever is starting the child process gets to determine the inheritance - it can use the current process environment, an empty environment or anything else it chooses. You want to add something to $PATH - copy the current process environment, modify $PATH, and pass this as the child process environment. Simple to do, and very explicit. Further, this also maps closer to NSPR, and all other process creation code I have seen in the past, OO or not. Combine these with the fact I can't think of anything going for Get/SetEnv(), and I must stick with my original opinion - that Get/SetEnv() on nsIProcess would suck :) Mark.
