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
Thanks very much for the detailed reply. Sadly, it seems like this
isn't quite the solution yet - my mounts are the defaults that you
get when you install cygwin:
$ mount
C:\cygwin\bin on /usr/bin type system (binmode)
C:\cygwin\lib on /usr/lib type system (binmode)
C:\cygwin on / type system (binmode)
c: on /cygdrive/c type system (binmode,noumount)
and hence I'm guessing that cygexec is already not being used. Any
other possibilities?
Thanks very much, Steve.
------------------------------------------------------------------------
------------------
Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre
FMRIB, John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726 (fax 222717)
[EMAIL PROTECTED] http://www.fmrib.ox.ac.uk/~steve
------------------------------------------------------------------------
------------------
--
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/
