delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2006/02/02/09:51:46

X-Spam-Check-By: sourceware.org
From: ericblake AT comcast DOT net (Eric Blake)
To: Steve Smith <steve AT fmrib DOT ox DOT ac DOT uk>
Cc: cygwin AT cygwin DOT com
Subject: Re: Exec and parent environment [attn tcltk maintainer]
Date: Thu, 02 Feb 2006 14:51:24 +0000
Message-Id: <020220061451.21213.43E21C6C000D7D5B000052DD22064244130A050E040D0C079D0A@comcast.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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

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

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

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.

--
Eric Blake

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019