On 11/05/10 19:59 , David Matthews wrote:
Michael Norrish wrote:
Incidentally, on the machine where Posix.Process.exec("/bin/ls", []) seg. faults, Unix.execute("/bin/ls", []) works correctly. The Basis library documentation I have for the Unix structure doesn't discuss how the argv component should be setup, but attempting
Unix.execute("/bin/ls", ["ls"])
prompts a message from ls saying that there is no file called ls.
This doesn't seem consistent.
Curiously, on the Macbook where Posix.Process.exec gives ENOTSUP, Unix.execute does work.
It turns out that on Mac OS X execv returns ENOTSUP if the process is multi-threaded. You need to use Posix.Process.fork first to start a new process: case Posix.Process.fork() of SOME _ => OS.Process.exit OS.Process.success | NONE => Posix.Process.exec("/bin/ls", ["ls"]);
Hmm. Thanks for going to the trouble of figuring this out. Is it clear what exit code the invoker will get in this situation? It looks to me as if it will get success, regardless of what happens in the forked child. If that's what happens, my feeling is that it's a bug (in Apple's design), and I'll have to have the parent hang around waiting for the child to finish. Of course, this is exactly what I was hoping to avoid by using exec in the first place. And it is important to get the right error code because it's all part of a build system that needs to know when to stop and when to continue.
(I just did a very simple-minded test which seemed to confirm that the exec-ed process's code is indeed lost if you use the idiom above. Boo hiss.)
Michael