Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com From: Christian Weinberger Subject: env -i specialities on cygwin Date: Fri, 3 Sep 2004 11:24:48 +0000 (UTC) Lines: 25 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet AT sea DOT gmane DOT org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 217.115.74.2 (Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7) Gecko/20040803 Firefox/0.9.3) X-IsSubscribed: yes If one want´s to start a new process without an environment, env -i will be the choice. In the cygwin enviroment this leads to problems if /bin or /usr/bin are not added to the PATH in the new process. In this case the cygwin1.dll is not in the path and will not be found be the process that just tries to start. This is true for all other DLLs that may be used by the cygwin executable. There are two options to avoid this: 1) Modify all shell scripts that use env -i to include /usr/bin in the PATH when porting appications to cygwin. This means lots of manual work since shell scripts are often not considered to be dynamic in autoconf/automake runs. 2) Modify the env binary to always include /usr/bin to the path, even if the -i switch is specified. But this will not just allow access to the DLLs but to all executables in the same directory. This may raise security problems. A third solution would be to have all cygwin DLLs in a separate directory where no executables reside. But this would be a more dramatic change to the distribution. Any comments are welcome! Regards, Christian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/