[MLton] Re: [MLton-commit] r6699

[Wesley W. Terpstra]

On Wed, Jun 17, 2009 at 5:45 PM, Matthew Fluet<fluet at tti-c.org> wrote:
> This also explains why the current implementation of create, that copies the
> whole environment via Posix.ProcEnv.environ (which would appear to have a
> PATH entry with the appropriate directory) fails.  The 'problem' is that the
> PATH environment variable returned by Posix.ProcEnv.environ has been
> cygwinified: it has '/usr/bin', not 'C:\cygwin\bin'.

This seems a problem.

> Of course, '/usr/bin'
> means nothing to CreateProcess/Windows, which I'm guessing is using the PATH
> to find cygwin1.dll (in C:\cygwin\bin) for a cygwin program.

Ahh... Of course!

> All in all, I think the way forward is clear:
>
>  * create {env = NONE, ...} should result in calling CreateProcess with a
>   NULL lpEnvironment; this is, by far, the most common case I would
>   think.

Why does this work? I don't understand how a cygwin program can call
another cygwin program with env = NONE. I would have expected this
means PATH still has /usr/bin. Unless the environment provided to
MLton from cygwin is a lie that has been translated from the real
environment and the real environment is what gets copied by
CreateProcess. If you set an environment variable in the calling
cygwin process, does the CreateProcess cygwin child see it?

>  * create {env = SOME [...], ...} should behave as currently implemented;
>   the user is responsible for establishing the correct environment (it is
>   just the case that the correct environment for a Cygwin program is
>   subtle)

Indeed.