bug#38: marked as done (No coding system used for environment variables)

[owner@emacsbugs.donarmstrong.com (Emacs bug Tracking System)]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]


Your message dated Tue, 24 Mar 2009 22:23:12 +0800
with message-id <49C8ECD0.2090706@gnu.org>
and subject line bug#38: Re: No coding system used for environment variables
has caused the Emacs bug report #38,
regarding No coding system used for environment variables
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
38: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=38
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 7600 bytes --]

From: Jason Rumney <jasonr@gnu.org>
To: submit@emacsbugs.donarmstrong.com
Subject: No coding system used for environment variables
Date: Wed, 05 Mar 2008 00:24:13 +0000
Message-ID: <47CDE82D.2020302@gnu.org>



-------- Original Message --------
Subject: 	No coding system used for environment variables
Date: 	Thu, 21 Feb 2008 22:40:40 +0100
From: 	Göran Uddeborg <goeran@uddeborg.se>
To: 	bug-gnu-emacs@gnu.org



It seems there is no coding system applied to values of environment
variables.

I'm running a system using UTF-8.  My locale is sv_SE.utf8.  And emacs
uses UTF-8 as default most of the time.  When I open a new file for
example.

I do have issues with strings coming from environment variables
though.  I first discovered this in the vm mail system, since it
misinterpreted the variable MAIL which has the value
/var/spool/mail/göran encoded in UTF-8.  (In case your mailer mangles
it, the last file name component is g &ouml; r a n.)  But it also
causes problems in various places, for example with functions relating
to the home directory.  $HOME is /home/göran (same last component as
before).

As an example, I start emacs in my home directory, and do a few
experiments in the scratch buffer (which has a "u" for coding system
in the mode line):

    default-directory
    "/home/göran/"

Looks good.  I see my &ouml;.

    (expand-file-name "")
    "/home/göran"

Ok too.

    (expand-file-name "~")
    "/home/g\303\266ran"

Here the octal codes for a UTF-8 encoded &ouml; is shown instead of
the &ouml; itself.  The source of ~ is the environment variable HOME.
But if I explicitly ask for that variable:

    (getenv "HOME")
    "/home/göran"

Here I see the &ouml;.

Let's have a bit more fun.  Here I try to expand a FILE with my own
name:

    (expand-file-name "göran")
    "/home/göran/göran"

Looks the way I expected it.  Now the same thing, explicitly saying to
put it in the home directory:

    (expand-file-name "~/göran")
    "/home/g\xc3\xb6ran/göran"

The &ouml; in the file name is ok.  The &ouml; in the directory name
is strange again, only this time it is shown in hex rather than octal.

I asked about this on gnu.emacs.help first,
(http://groups.google.se/group/gnu.emacs.help/browse_thread/thread/80258d0a17e37138/75411fce63db9b2c#75411fce63db9b2c)
I was unsure if it was a bug or my lack of understanding.  But two
other posters have suggested I report it as a bug.



In GNU Emacs 22.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.12.1)
 of 2007-11-06 on xenbuilder2.fedora.redhat.com
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure  '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-pop' '--with-sound' '--with-gtk' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -DSYSTEM_PURESIZE_EXTRA=16777216 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: sv_SE.utf8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  which-function-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
? <return> M-< C-n C-k C-k <switch-frame> <switch-frame> 
<switch-frame> C-y <switch-frame> <next> <down> <down> 
<down> <up> <up> <up> <up> <up> <up> <up> <up> p <switch-frame> 
<switch-frame> <switch-frame> <down-mouse-2> <mouse-2> 
<backspace> C-j C-x 4 C-f . e m <tab> <return> C-s 
v m - s p o o M-< C-x C-f . v m C-g C-x C-f ~ / . v 
m <return> C-s C-g C-_ C-s v m - s p o o l - f i l 
e s C-a ; C-x C-s <help-echo> <switch-frame> <switch-frame> 
q <switch-frame> C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-c C-g <switch-frame> <help-echo> 
<help-echo> C-x M q q <help-echo> C-x M n n n n n n 
n M-< C-s S E C C-a SPC <switch-frame> <help-echo> 
C-x C-f ~ / N <tab> <return> C-x c C-a C-k r p m g 
r e p SPC l h a <return> ! <help-echo> <help-echo> 
<switch-frame> <switch-frame> <help-echo> <switch-frame> 
<switch-frame> <help-echo> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <help-echo> <switch-frame> 
d <switch-frame> <help-echo> C-u C-u C-u <f6> C-x o 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p M-> 
C-x o C-x C-f <M-backspace> <M-backspace> u p d <return> 
<help-echo> <switch-frame> M-> C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p SPC n n d d d e <next> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <left> = C-c C-c 
SPC SPC <backspace> <backspace> <down-mouse-2> <mouse-2> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
n <down-mouse-2> <mouse-2> s I <tab> <return> q d SPC 
<switch-frame> M-x r e p o <tab> r <tab> <return>

Recent messages:
End of message 1059 from Göran Uddeborg
Loading vm-digest...done
Decoding MIME message... done
End of message 1 from Gunilla Christensson
1 message saved to buffer INBOX
Quitting...
Decoding MIME message... done
End of message 1060 from Göran Uddeborg
Making completion list...
Loading emacsbug...done







[-- Attachment #3: Type: message/rfc822, Size: 3873 bytes --]

From: Jason Rumney <jasonr@gnu.org>
To: Chong Yidong <cyd@stupidchicken.com>
Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, 38-done@emacsbugs.donarmstrong.com
Subject: bug#38: Re: No coding system used for environment variables
Date: Tue, 24 Mar 2009 22:23:12 +0800
Message-ID: <49C8ECD0.2090706@gnu.org>

Chong Yidong wrote:
> Jason Rumney <jasonr@gnu.org> writes:
>
>   
>>> Two objections were made to Jason's patch: (i) some coding systems are
>>> not ready until some .elc files get loaded (relevant for special cases,
>>> such as the EMACS_LOAD_PATH variable), and (ii) DECODE_FILE causes GC,
>>> so variables such as `nm' in Fexpand_file_name may not point to valid
>>> data after that.
>>>
>>> If no elegant solution is forthcoming, I'd suggest simply documenting
>>> (i) as a limitation, and dealing with (ii) by simply turning off GC in
>>> the affected part of the function.
>>>       
>> I think the GC part can be handled the same way as in bug #93
>>     
>
> Okay.  Could you put your patch back in, with the proper GC handling?
>   

I've finally looked at this, and the case for Fsubstitute_file_name 
looks much simpler than Fexpand_file was. Only one Lisp_String was 
internally referenced, and that was already copied on DOS_NT, so I moved 
the copy outside of the #ifdef so that all platforms now work with a 
copy of the original string.