X-Spam-Check-By: sourceware.org
Date: Thu, 2 Feb 2006 12:11:57 -0500 (EST)
From: Igor Peshansky <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: Eric Blake <ericblake AT comcast DOT net>
cc: cygwin AT cygwin DOT com
Subject: Re: Exec and parent environment [attn tcltk maintainer]
In-Reply-To: <020220061704.21728.43E23BAA00009920000054E022092246270A050E040D0C079D0A@comcast.net>
Message-ID: <Pine.GSO.4.63.0602021209460.9860@access1.cims.nyu.edu>
References: <020220061704 DOT 21728 DOT 43E23BAA00009920000054E022092246270A050E040D0C079D0A AT comcast DOT net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Thu, 2 Feb 2006, Eric Blake wrote:

> > > But if cygexec mounting is turned on, then a native windows program
> > > in that mount point will be mistakenly treated as a cygwin program,
> > > such that cygwin tries to use only the cygwin method for passing the
> > > environment to the child program.  My guess is that you are calling
> > > tclsh from a cygwin shell (bash?), and that cygwin is assuming the
> > > child (tclsh) can understand cygwin's environment because it lives
> > > in /bin, even though it is a windows native executable and needs the
> > > windows environment.
> >
> > Well, tclsh is a *Cygwin* executable that uses native Windows calls
> > (CreateProcess) under the covers (in tcl84.dll).  I'm not sure if it
> > would even help to be able to mount it as a "non-cygwin executable"...
> > CGF?
>
> Really?
>
> $ cygcheck tclsh
> Found: C:\cygwin\bin\tclsh.exe
> C:/cygwin/bin/tclsh.exe
> $
>
> My understanding of the cygexec magic was that if it was determined that
> an .exe had a startup dependency on cygwin1.dll, but tclsh has NO dll
> dependencies at startup (any dlls are pulled in with dynamic loads
> during execution), so how would cygwin1.dll be able to think that tclsh
> is a cygwin executable?

Because tclsh.exe is a symlink to tclsh84.exe, which has

$ ls -l /bin/tclsh.exe
lrwxrwxrwx  1 Administrators SYSTEM 11 Jul 30  2004 /bin/tclsh.exe -> tclsh84.exe*
$ cygcheck tclsh84
Found: C:\cygwin\bin\tclsh84.exe
C:/cygwin/bin/tclsh84.exe
  C:\WINDOWS\System32\KERNEL32.dll
    C:\WINDOWS\System32\ntdll.dll
  C:\cygwin\bin\cygwin1.dll
    C:\WINDOWS\System32\ADVAPI32.DLL
      C:\WINDOWS\System32\RPCRT4.dll
  C:\cygwin\bin\tcl84.dll
    C:\WINDOWS\System32\USER32.dll
      C:\WINDOWS\System32\GDI32.dll

I made the same mistake initially... :-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha AT cs DOT nyu DOT edu | igor AT watson DOT ibm DOT com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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/