X-Spam-Check-By: sourceware.org From: ericblake AT comcast DOT net (Eric Blake) To: Steve Smith 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: 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 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/