Andy Wingo wrote: >#!/bin/sh >export FOO=bar >exec guile $0 "$@" >!#
That introduces all the complexity of using another language interpreter, one I've chosen not to write my program in. I don't much fancy working round a gotcha by importing another series of gotchas. Fundamentally, it seems like an admission of defeat. With care it would work, but means that Guile is not itself the platform on which to write a Unix program. Maybe you're OK with the idea that Guile programs aren't meant to run in their own right. Would you be OK with documenting it? It also means that the Guile program isn't actually seeing the user's environment, and so doesn't accurately pass that environment through to anything that it runs in turn. Working around that would involve some hairy and error-prone shell code. >This is certainly possible to do. Actually I would guess that this >works: > > (setlocale LC_ALL "") That succeeds in signalling an error in any case where the environmental locale doesn't exist, but that's not really what I want. If the framework didn't perform an implicit setlocale, and so didn't mar my output, I don't then want to make things break. That approach is also totally specific to the setlocale warning. If program-running-with-unclean-output were to exist, it should also cover uncleanliness due to auto-compile banners (bug#16364). It would be the solution (though not a great one) to both problems. >Does any of this work for you? Shell script wrapper is the closest so far, but it's nasty. You haven't proposed any real solution. The really simple solution would be to remove this switch from the environment entirely, and remove the implicit setlocale from the startup sequence entirely. The environment was always the wrong place for the switch, and there's no benefit in the implicit setlocale being as early as it is. The decision on whether to engage with the user's locale is then made entirely by the program, as part of its ordinary execution. If it wants to use the user's locale, it executes (setlocale LC_ALL ""). If it wants non-default handling of errors, it executes that in the dynamic scope of whatever throw or catch handler it likes. If it doesn't want to use the user's locale, it doesn't execute that. Bonus: works identically on older Guile versions. If you won't go for the simple solution, then a proper solution that maintains the default implicit setlocale would be to have a switch in a magic comment in the program file. Something like "#!GUILE_INSTALL_LOCALE=0\n!#\n" immediately following the program's initial #!...!# block. This is ignored as a comment by older Guile versions. The semantic on newer versions would be that the setting given there (which may be 0 or 1) determines conclusively whether the implicit setlocale happens. The environment variable would take effect as it currently does only for programs not containing this kind of setting. -zefram
