X-Spam-Check-By: sourceware.org
Date: Thu, 2 Feb 2006 10:06:56 -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: Steve Smith <steve AT fmrib DOT ox DOT ac DOT uk>, cygwin AT cygwin DOT com
Subject: Re: Exec and parent environment [attn tcltk maintainer]
In-Reply-To: <020220061451.21213.43E21C6C000D7D5B000052DD22064244130A050E040D0C079D0A@comcast.net>
Message-ID: <Pine.GSO.4.63.0602020956580.9860@access1.cims.nyu.edu>
References: <020220061451 DOT 21213 DOT 43E21C6C000D7D5B000052DD22064244130A050E040D0C079D0A 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:

> Ugh - top-posting reformatted.  http://cygwin.com/acronyms/#TOFU

Good point -- I should start including the link to that acronym too... :-)

> > >> When I type "env" the environment appears fine. However, when I
> > >> start  a
> > >> tclsh and type
> > >>
> > >> puts [ exec sh -c "env" ]
> > >>
> > >> the environment is almost empty - this is new behaviour, the whole
> > >> environment got fully passed through until recently.
> > >
> > > Sounds like YA case of
> > > http://sourceware.org/ml/cygwin/2006-01/msg00938.html.  tclsh is one
> > > of the few programs in /bin that does not link against cygwin1.dll,
> > > but uses Windows directly.  So it probably needs to be taught how to
> > > interact with cygwin's updated environment scheme.
>
> > Thanks for the feedback. So does this mean that it is the tcl that is
> > bundled with Cygwin that is broken?
>
> Actually, on further thought, it might be something that cygwin needs to
> fix.  Do you mount /bin as cygexec?  (Hint - attaching the output of
> cygcheck -svr as a text attachment would have answered this question).
> Prior to cygwin 1.5.19, it was suggested that mounting /bin as cygexec
> would speed up operations of cygwin programs, since the bulk of the
> files in /bin are linked against cygwin1.dll.  In 1.5.19, however, cgf
> improved cygwin to automatically detect wheter an application is linked
> against cygwin or is a native windows program, and in the process made
> it so that only native windows programs are handed a native windows
> environment.

I've been thinking along the same lines.  Actually, as of Cygwin 1.5.19,
any program that links to Cygwin1.dll will behave as if it's on a cygexec
mount...  I wonder if there needs to be a symmetric option to mount to
indicate a non-Cygwin executable...

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

> From there, when you do the exec in tclsh, the grandchild sh sees the
> same environment that tclsh saw.
>
> > Is there an easy workaround?
>
> If my hypothesis was correct, then remount /bin to no longer be cygexec
> (cygexec mount points no longer make sense, now that cygwin can
> autodetect programs linked against cygwin).  Or wait and see if a future
> snapshot of cygwin learns to recognize native windows apps that live in
> a cygexec mountpoint.

Since Cygwin automatically detects Cygwin programs, removing the cygexec
bit won't help.  I guess there isn't an easy workaround at the moment,
short of patching tclsh appropriately and building your own.  That might
not be as hard as it sounds, and I'm sure the maintainer will appreciate a
ready and tested patch.

> Or, if you are ambitious, figure out a way to package two versions of
> tcltk in cygwin; the native tcltk is a requirement (cgf wants the
> insight debugger to work no matter what), but a cygwin-aware tcltk would
> also be nice.  The issue has come up before, search the mailing list
> archives.  Until someone comes up with a good solution, tclsh will
> remain one of the few windows-native programs distributed in /bin.

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