zsh-users
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: Stucki <stucki@math.fu-berlin.de>, zsh-users@math.gatech.edu
Subject: Re: How to NOT allow LC_COLLATE to corrupt globbing ???
Date: Mon, 07 Dec 1998 14:57:03 +0100	[thread overview]
Message-ID: <9812071357.AA69927@ibmth.df.unipi.it> (raw)
In-Reply-To: "Stucki"'s message of "Mon, 07 Dec 1998 14:44:48 NFT." <19981207144447.A13964@math.fu-berlin.de>

Stucki wrote:
> So now I'd like to ***compile*** my zsh in a way that makes sure
> I *always* use the standard collating sequence like LC_COLLATE=C
> (or may be LC_COLLATE=us).
> 
> Is there a way to configure this in, by editing some config-files ???
> 
> (changing 'config.h' *after* running 'configure'
>  to contain '#define HAVE_LOCALE_H 0' did *not* help!)

I just reread that and the first thing I'd suggest is not defining
HAVE_LOCALE_H at all, since most of the tests are #ifdef's.

If that's not it, here's what I wrote before I realised what the
problem probably was.

zsh will only ever call setlocale() if LC_ALL is defined, which
usually happens in locale.h; zsh will not define it itself.  So either
the definition is creeping in some other way on your system --- you
could look at the post-prerprocessor output to see what files are
being included --- or the locale you are in is the default one.  If
it's the former you might try sticking #undef LC_ALL at the end of
system.h, since config.h probably gets included too early to do
anything about it without some more detective work.  If it's the
second (which seems pretty unlikely) you can't get away without at
least one call to setlocale().

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


  reply	other threads:[~1998-12-07 14:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-12-07 13:44 Stucki
1998-12-07 13:57 ` Peter Stephenson [this message]
1998-12-07 16:16 ` Bart Schaefer
1998-12-07 16:44   ` Bruce Stephens

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

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

  git send-email \
    --in-reply-to=9812071357.AA69927@ibmth.df.unipi.it \
    --to=pws@ibmth.df.unipi.it \
    --cc=stucki@math.fu-berlin.de \
    --cc=zsh-users@math.gatech.edu \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

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 NNTP newsgroup(s).