GNU bug report logs -
#15260
cannot build in a directory with non-ascii characters
Previous Next
Reported by: Glenn Morris <rgm <at> gnu.org>
Date: Tue, 3 Sep 2013 17:47:02 UTC
Severity: wishlist
Found in version 24.3
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #43 received at 15260 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 25 Oct 2013 22:27:19 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 15260 <at> debbugs.gnu.org
>
> > Date: Fri, 25 Oct 2013 21:46:52 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 15260 <at> debbugs.gnu.org
> >
> > > but there are still
> > > problems later on, again related to Emacs mistakenly believing that
> > > certain directories do not exist, when they do (Warning: arch-dependent
> > > data dir `...' No such file or directory; etc).
> > >
> > > The "non-ascii srcdir == builddir" case fails even earlier, due to not
> > > finding etc.
> >
> > OK, I will take a closer look. Thanks for the info.
>
> I think I see the problem. All those PATH_* variables that come from
> epaths.h yield encoded file names (because they were written by the
> shell). But we never decode them before using them in init_callproc
> and init_callproc_1. Similar things happen with decode_env_path: it
> calls 'getenv', but never decodes the values it gets from that.
>
> I will take a crack on fixing these.
We definitely need to decode file names in init_callproc_1,
init_callproc, and init_lread.
But here's where things get hairy: when temacs starts, preloaded Lisp
files are not yet loaded, and consequently file-name-coding-system and
default-file-name-coding-system are both nil. In such a case,
currently DECODE_FILE is a no-op.
So we need some way of getting temacs to know what coding-system to
use to decode file names during its initialization phase, without
relying on the database we have in locale-language-names. This
probably calls for a separate variable, init-file-name-coding-system,
say. But how to assign a correct value to it?
I understand that most Posix systems nowadays use UTF-8 for file
names, so I guess we can fall back on that. On MS-Windows, there's a
system call that returns the necessary information, so there's no
problem for MS-Windows. The question is what to do for Posix systems
that don't use UTF-8? I see 2 possibilities:
. Try to parse the value of LANG with some shell or Sed script, and
come up with a suitable value.
. Ask the user to specify the encoding as a switch to the configure
script.
In both cases, communicate the value to temacs via --eval on its
command line.
Comments and opinions are welcome.
This bug report was last modified 11 years and 202 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.