This is the mail archive of the
mailing list for the Cygwin project.
Re: problem with run command and the environment
- From: Brian Dessent <brian at dessent dot net>
- To: cygwin at cygwin dot com
- Date: Thu, 19 Jan 2006 12:06:38 -0800
- Subject: Re: problem with run command and the environment
- References: <email@example.com>
- Reply-to: cygwin at cygwin dot com
Jeff Hardy wrote:
> Is this fact useful to the discussion? The run.exe
> executable that shows a limited view of the
> environment under the latest cygwin is exactly the
> same executable that runs on the older version of
> cygwin that I have that does NOT exhibit the same
> pathological behavior of displaying the limited
> environment. The same run.exe binary behaves
> differently on two different cygwins. On the older
> cygwin it displays the full environment and on the
> newer cygwin, it displays a severely limited view of
> the environment.
The internal behavior changed in Cygwin, which is why you see the
difference with the same run binary. But that doesn't mean it's not
run's fault -- just as if you relied on undefined behavior in a program
and the compiler changed how it internally performed some optimization,
crashing your (broken) code.
Similarly, run is a Cygwin program but it directly calls CreateProcess.
This puts it in the same rough footing as if a program opened a file
with CreateFile and then tried to pass that handle to Cygwin functions.
In both cases the program is violating the abstraction levels -- Cygwin
apps should use the standard posix API (such as fork/exec). Calling the
win32 API directly goes behind Cygwin's back and can cause all manor of
In the case of run it's necessary to call CreateProcess for the
functionality required, but this also means that it has to be careful to
do so in a way that is compatible with Cygwin -- in this case syncing
the environment first.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html