Setting LOCALE for Tcl only
Charlie Bursell
simple expr command.
The error message is"syntax error in expression "1.5-1.3": extra
tokens at end of expression"
The command is: "set myVar [expr 1.5-1.3]"
Starngly enough we were able to resolve the problem by setting the
LOCALE environment to English. Is there a method to set the LOCALE
for Tcl without changing the user's environment? I have asked him to
try setting the env array just prior to the expr command to see if
that works. I have not received a response yet.
I was under the impression that TCl was a universal language. Does is
work in the English locale only or are there other eversions for other
languages.
Thanks
Charlie Bursell
Don Porter
> I have a client in Europe that is getting an error when running a
> simple expr command.
>
> The error message is"syntax error in expression "1.5-1.3": extra
> tokens at end of expression"
>
> The command is: "set myVar [expr 1.5-1.3]"
Short answer: Upgrade to Tcl 8.5.
> Starngly enough we were able to resolve the problem by setting the
> LOCALE environment to English. Is there a method to set the LOCALE
> for Tcl without changing the user's environment?
Longer answer involves a rant about the deep misfeature of a global
locale resource, that is settable by each library. No, there is no
way for Tcl to set the locale environment for its own needs only in
a manner that no other library can intervene and break things again.
Precisely what program is running on precisely what platform that
exhibits the problem you report? The Tcl shared library sets the
locale preferences it requires during initialization. The problem
reported indicates that either 1) the program using Tcl is failing
to initialize it properly; or 2) after Tcl is initialized properly,
some other library in the program is changing the global locale
resource to a new setting that breaks Tcl.
The only reliable solution is for Tcl to stop calling system routines
that have behavior controlled by the locale. Tcl 8.5 mostly does this.
Thus back to the short answer: upgrade to Tcl 8.5.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Charlie Bursell
> |http://math.nist.gov/~DPorter/ NIST |
> |______________________________________________________________________|
Don:
I am confused about the part of your response that says " after Tcl is
initialized properly,
some other library in the program is changing the global locale
resource to a new setting that breaks Tcl."
It seems to me the global locale would be set to the environment
locale. It is when the environment locale is other than english the
problem occurs not due to some other program changing it.
Thanks for your response
Alexandre Ferrieux
> No, there is no
> way for Tcl to set the locale environment for its own needs only in
> a manner that no other library can intervene and break things again.
What about putting in front of your PATH a script called "tclsh" and
doing
#! /bin/sh
LC_ALL=foo export LC_ALL
exec /usr/bin/tclsh "$@"
-Alex
Don Porter
If you don't answer my questions, I cannot effectively help you.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Donal K. Fellows
> I am confused about the part of your response that says " after Tcl is
> initialized properly,
> some other library in the program is changing the global locale
> resource to a new setting that breaks Tcl."
>
> It seems to me the global locale would be set to the environment
> locale. It is when the environment locale is other than english the
> problem occurs not due to some other program changing it.
The C locale system is... something I usually try to avoid thinking
about. It's got rather a lot wrong with it, but most of the problems
stem from about the time when a shared library decides that it wants to
override the settings set on an executable-wide basis. That's what's
happening to your client. Go back and answer Don Porter's questions and
we'll be able to help you much more effectively. (And upgrading to Tcl
8.5 stands a good chance of clearing the problems too, because much of
Tcl was rewritten to be wholly locale-independent.)
(Up to 8.4, Tcl *really* prefers the "C" locale...)
Donal.
Ralf Fassel
| I am confused about the part of your response that says " after Tcl
| is initialized properly, some other library in the program is
| changing the global locale resource to a new setting that breaks
| Tcl."
|
| It seems to me the global locale would be set to the environment
| locale. It is when the environment locale is other than english the
| problem occurs not due to some other program changing it.
We found that our TCL-based program worked fine *until* the user
opened the Printer Dialog for a specific printer. Some routine in the
printer driver DLL for this particular printer changed the Locale so
that the decimal separator was reset from "." to ",". As a
consequence, the system number parsing routines reported an error for
"1.23" from then on, whereas "1,23" was recognized as a floating point
number from then on. TCL 8.5 obviously does not call system number
parsing routines, so it is not affected by this Locale change.
HTH
R'
Alexandre Ferrieux
>
> We found that our TCL-based program worked fine *until* the user
> opened the Printer Dialog for a specific printer. Some routine in the
> printer driver DLL for this particular printer changed the Locale
Interesting. Printer drivers are an interesting species of elegant and
efficient software (25MB seems to be a minimum for a HP printer, and
in these 25MB it doesn't get a chance to wipe its footprints...).
By the way, in Windows, is this locale-change system-wide, or just
inherited by children processes ?
-Alex
Charlie Bursell
wrote:Sorry, I should have answered the questions, I should have noted that
Tcl is running on Windows XP. The application is an integration
engine (Cloverleaf) that uses Tcl as an embedded language.
Ralf Fassel
| Printer drivers are an interesting species of elegant and efficient
| software
Do I smell a little irony here? ;-)
| By the way, in Windows, is this locale-change system-wide, or just
| inherited by children processes ?
Interesting question. We haven't investigated that, but resolved to
wrapping each call to the printer dialog into
/* Sometimes the PrintDlg() VC library function changes the LC
locale on _first_ call which breaks numerical expressions in
TCL. Try to keep the old value.
*/
static char *oldlocale;
static void save_locale() {
if (!oldlocale) {
oldlocale = setlocale(LC_ALL,NULL);
/* make a copy of static info overwritten at next call. If this
fails with out-of-mem at very first call, life is hard... */
if (oldlocale) oldlocale = _strdup(oldlocale);
}
}
static void restore_locale() {
/* if we had a locale, restore it */
if (oldlocale) {
setlocale(LC_ALL, oldlocale);
}
}
...
save_locale();
PrintDlg(...);
restore_locale();
BTW, IIRC changing the system LC_* settings in the approriate system
dialog did not affect our application, probably because we did not
call setlocale() at all. But obviously the printer dialog in question
called setlocale(), which then set the defaults for the process.
R'