unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Zefram <zefram@fysh.org>
To: Andy Wingo <wingo@pobox.com>
Cc: 22905@debbugs.gnu.org
Subject: bug#22905: GUILE_INSTALL_LOCALE produces unavoidable noise
Date: Tue, 9 Aug 2016 20:26:30 +0100	[thread overview]
Message-ID: <20160809192630.GJ24721@fysh.org> (raw)
In-Reply-To: <87ziollu3d.fsf@pobox.com>

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





      reply	other threads:[~2016-08-09 19:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 14:13 bug#22905: GUILE_INSTALL_LOCALE produces unavoidable noise Zefram
2016-08-07 21:58 ` Andy Wingo
2016-08-07 23:00   ` Zefram
2016-08-08 20:17     ` Andy Wingo
2016-08-08 21:02       ` Zefram
2016-08-09 17:39         ` Andy Wingo
2016-08-09 19:26           ` Zefram [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160809192630.GJ24721@fysh.org \
    --to=zefram@fysh.org \
    --cc=22905@debbugs.gnu.org \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).