On Aug 1 12:09, [EMAIL PROTECTED] wrote: > It appears that tcsh treats the "TZ" environmental variable in a special > way - upon entry into tcsh, some commands see TZ as set. Using unsetenv to > attempt to unset it is fruitless: > > bash-3.2$ unset TZ > bash-3.2$ printenv TZ > bash-3.2$ echo $TZ > > bash-3.2$ bash -c "printenv TZ" > bash-3.2$ tcsh > tcsh$ printenv TZ > tcsh$ echo $TZ > GMTST0GMTDT-1,M3.5.0/1,M10.5.0/2 > tcsh$ bash -c "printenv TZ" > GMTST0GMTDT-1,M3.5.0/1,M10.5.0/2 > tcsh$ unsetenv TZ > tcsh$ printenv TZ > tcsh$ echo $TZ > GMTST0GMTDT-1,M3.5.0/1,M10.5.0/2 > tcsh$ bash -c "printenv TZ" > GMTST0GMTDT-1,M3.5.0/1,M10.5.0/2
It's not tcsh but Cygwin. tcsh just happens to call tzset once in a while, which, under Cygwin, sets the TZ environment variable. This is arguably wrong, since the tzset() function is per POSIX supposed to *read* the TZ environment variable, but it doesn't set it. I fixed that in Cygwin in CVS, but the patch will not make it into a release for some time. So, better find some workaround (like, for instance, create wrapper scripts around your MSVC applications using bash). > All opinions expressed are my own [etc, etc, etc] Disclaimers like that are against site policy, please see http://sources.redhat.com/lists.html. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
