From unknown Sat Aug 16 16:14:25 2025 X-Loop: don@donarmstrong.com Subject: bug#38: No coding system used for environment variables Reply-To: Jason Rumney , 38@debbugs.gnu.org Resent-From: Jason Rumney Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 05 Mar 2008 00:30:03 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 38 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.12046766803623 (code B ref -1); Wed, 05 Mar 2008 00:30:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,IMPRONONCABLE_2, SPF_HELO_PASS autolearn=no version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 5 Mar 2008 00:24:40 +0000 Received: from mk-outboundfilter-4.mail.uk.tiscali.com (mk-outboundfilter-4.mail.uk.tiscali.com [212.74.114.32]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m250OXmC003617 for ; Tue, 4 Mar 2008 16:24:35 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALV2zUdTQxds/2dsb2JhbAAIrj8 X-IronPort-AV: E=McAfee;i="5200,2160,5244"; a="19420566" X-IronPort-AV: E=Sophos;i="4.25,444,1199664000"; d="scan'208";a="19420566" X-IP-Direction: OUT Received: from i-83-67-23-108.freedom2surf.net (HELO [127.0.0.1]) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2008 00:24:15 +0000 Message-ID: <47CDE82D.2020302@gnu.org> Date: Wed, 05 Mar 2008 00:24:13 +0000 From: Jason Rumney User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: submit@debbugs.gnu.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit -------- Original Message -------- Subject: No coding system used for environment variables Date: Thu, 21 Feb 2008 22:40:40 +0100 From: Göran Uddeborg 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 ö 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 ö. (expand-file-name "") "/home/göran" Ok too. (expand-file-name "~") "/home/g\303\266ran" Here the octal codes for a UTF-8 encoded ö is shown instead of the ö 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 ö. 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 ö in the file name is ok. The ö 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: ? M-< C-n C-k C-k C-y p C-j C-x 4 C-f . e m C-s v m - s p o o M-< C-x C-f . v m C-g C-x C-f ~ / . v m 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 q 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 C-x M q q C-x M n n n n n n n M-< C-s S E C C-a SPC C-x C-f ~ / N C-x c C-a C-k r p m g r e p SPC l h a ! d C-u C-u C-u 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 u p d 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 = C-c C-c SPC SPC n s I q d SPC M-x r e p o r 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 From unknown Sat Aug 16 16:14:25 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) X-Loop: don@donarmstrong.com From: help-debbugs@gnu.org (Emacs bug Tracking System) To: Jason Rumney Subject: bug#38 closed by Jason Rumney (Re: No coding system used for environment variables) Message-ID: References: <47CDEBFD.1060603@gnu.org> <47CDE82D.2020302@gnu.org> X-Emacs-PR-Message: they-closed 38 X-Emacs-PR-Package: emacs Reply-To: 38@debbugs.gnu.org Content-Type: multipart/mixed; boundary="----------=_1204678204-6746-1" This is a multi-part message in MIME format... ------------=_1204678204-6746-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This is an automatic notification regarding your bug report which was filed against the emacs package: #38: No coding system used for environment variables It has been closed by Jason Rumney . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Jason Rumney by replying to this email. --=20 38: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D38 Emacs Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1204678204-6746-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit >From jasonr@gnu.org Tue Mar 4 16:40:52 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=0.5 required=4.0 tests=AWL,SPF_HELO_PASS autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 38-done) by emacsbugs.donarmstrong.com; 5 Mar 2008 00:40:52 +0000 Received: from mk-outboundfilter-3.mail.uk.tiscali.com (mk-outboundfilter-3.mail.uk.tiscali.com [212.74.114.23]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m250elUt006064 for <38-done@emacsbugs.donarmstrong.com>; Tue, 4 Mar 2008 16:40:49 -0800 X-Trace: 54604578/mk-outboundfilter-1.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/83.67.23.108 X-SBRS: None X-RemoteIP: 83.67.23.108 X-IP-MAIL-FROM: jasonr@gnu.org X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMd6zUdTQxds/2dsb2JhbAAIriw X-IP-Direction: OUT Received: from i-83-67-23-108.freedom2surf.net (HELO [127.0.0.1]) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2008 00:40:30 +0000 Message-ID: <47CDEBFD.1060603@gnu.org> Date: Wed, 05 Mar 2008 00:40:29 +0000 From: Jason Rumney User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFVkZGVib3Jn?= CC: bug-gnu-emacs@gnu.org, 38-done@debbugs.gnu.org Subject: Re: No coding system used for environment variables References: <200802212140.m1LLeebW008878@freddi.uddeborg.se> In-Reply-To: <200802212140.m1LLeebW008878@freddi.uddeborg.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Version: 22.1.92 Göran Uddeborg wrote: > It seems there is no coding system applied to values of environment > variables. > Thank you for your report. This should be now fixed for 22.2. ------------=_1204678204-6746-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit >From jasonr@gnu.org Tue Mar 4 16:24:39 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,IMPRONONCABLE_2, SPF_HELO_PASS autolearn=no version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 5 Mar 2008 00:24:40 +0000 Received: from mk-outboundfilter-4.mail.uk.tiscali.com (mk-outboundfilter-4.mail.uk.tiscali.com [212.74.114.32]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m250OXmC003617 for ; Tue, 4 Mar 2008 16:24:35 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALV2zUdTQxds/2dsb2JhbAAIrj8 X-IronPort-AV: E=McAfee;i="5200,2160,5244"; a="19420566" X-IronPort-AV: E=Sophos;i="4.25,444,1199664000"; d="scan'208";a="19420566" X-IP-Direction: OUT Received: from i-83-67-23-108.freedom2surf.net (HELO [127.0.0.1]) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2008 00:24:15 +0000 Message-ID: <47CDE82D.2020302@gnu.org> Date: Wed, 05 Mar 2008 00:24:13 +0000 From: Jason Rumney User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: submit@debbugs.gnu.org Subject: No coding system used for environment variables Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit -------- Original Message -------- Subject: No coding system used for environment variables Date: Thu, 21 Feb 2008 22:40:40 +0100 From: Göran Uddeborg 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 ö 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 ö. (expand-file-name "") "/home/göran" Ok too. (expand-file-name "~") "/home/g\303\266ran" Here the octal codes for a UTF-8 encoded ö is shown instead of the ö 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 ö. 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 ö in the file name is ok. The ö 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: ? M-< C-n C-k C-k C-y p C-j C-x 4 C-f . e m C-s v m - s p o o M-< C-x C-f . v m C-g C-x C-f ~ / . v m 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 q 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 C-x M q q C-x M n n n n n n n M-< C-s S E C C-a SPC C-x C-f ~ / N C-x c C-a C-k r p m g r e p SPC l h a ! d C-u C-u C-u 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 u p d 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 = C-c C-c SPC SPC n s I q d SPC M-x r e p o r 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 ------------=_1204678204-6746-1-- From unknown Sat Aug 16 16:14:25 2025 X-Loop: don@donarmstrong.com Subject: bug#38: No coding system used for environment variables Reply-To: Jason Rumney , 38@debbugs.gnu.org Resent-From: Jason Rumney Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 05 Mar 2008 09:05:04 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 38 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 38-submit@emacsbugs.donarmstrong.com id=B38.12047074817784 (code B ref 38); Wed, 05 Mar 2008 09:05:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=0.3 required=4.0 tests=AWL,MURPHY_DRUGS_REL8, SPF_HELO_PASS autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 38) by emacsbugs.donarmstrong.com; 5 Mar 2008 08:58:01 +0000 Received: from mk-outboundfilter-4.mail.uk.tiscali.com (mk-outboundfilter-4.mail.uk.tiscali.com [212.74.114.32]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m258vqgw007778 for <38@emacsbugs.donarmstrong.com>; Wed, 5 Mar 2008 00:57:54 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAACvvzUdTQxds/2dsb2JhbAAIqzU X-IronPort-AV: E=McAfee;i="5200,2160,5244"; a="19559184" X-IP-Direction: OUT Received: from i-83-67-23-108.freedom2surf.net (HELO [127.0.0.1]) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2008 08:57:34 +0000 Message-ID: <47CE607B.1000708@gnu.org> Date: Wed, 05 Mar 2008 08:57:31 +0000 From: Jason Rumney User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: YAMAMOTO Mitsuharu CC: =?UTF-8?Q?G=C3=B6ran?= Uddeborg , bug-gnu-emacs@gnu.org, 38@debbugs.gnu.org References: <200802212140.m1LLeebW008878@freddi.uddeborg.se> <47CDEBFD.1060603@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit YAMAMOTO Mitsuharu wrote: > 2008-03-05 Jason Rumney > * fileio.c (Fexpand_file_name): Decode home directory names. > (Fsubstitute_in_file_name): Decode substituted variables. > > But I'd strongly suggest to revert this changes at this timing of > pretest for upcoming Emacs 22.2. It fixes a serious bug. Users with non-ASCII names in their user names get strange behaviour of filename expansion. > First, some coding systems are not > ready until some .elc files get loaded (a chicken-and-egg problem). > It should not present a chicken and egg problem, as no files are loaded during bootstrap that require expansion of ~ or environment variables. > Second, as DECODE_FILE causes GC and string compaction in general, > some variables such as `nm' in Fexpand_file_name may not point to > valid data after that. This is a problem on some systems that still do not support stack marking for GC protection of such variables. But I think this bug is important enough to fix those problems rather than revert the patch. > You may also want to see a related patch in > http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html > Was there a problem with that patch? Why was it not installed at the time? From unknown Sat Aug 16 16:14:25 2025 X-Loop: don@donarmstrong.com Subject: bug#38: No coding system used for environment variables Reply-To: YAMAMOTO Mitsuharu , 38@debbugs.gnu.org Resent-From: YAMAMOTO Mitsuharu Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 05 Mar 2008 09:25:03 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 38 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 38-submit@emacsbugs.donarmstrong.com id=B38.120470862411019 (code B ref 38); Wed, 05 Mar 2008 09:25:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=0.0 required=4.0 tests=MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 38) by emacsbugs.donarmstrong.com; 5 Mar 2008 09:17:04 +0000 Received: from mathmail.math.s.chiba-u.ac.jp (ntp.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m259GvOb011010 for <38@emacsbugs.donarmstrong.com>; Wed, 5 Mar 2008 01:16:59 -0800 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 816332C4A; Wed, 5 Mar 2008 18:16:45 +0900 (JST) Date: Wed, 05 Mar 2008 18:16:45 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Jason Rumney Cc: =?UTF-8?Q?G=C3=B6ran?= Uddeborg , bug-gnu-emacs@gnu.org, 38@debbugs.gnu.org In-Reply-To: <47CE607B.1000708@gnu.org> References: <200802212140.m1LLeebW008878@freddi.uddeborg.se> <47CDEBFD.1060603@gnu.org> <47CE607B.1000708@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 =?UTF-8?Q?(Shij=C5=8D)?= APEL/10.6 Emacs/23.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Wed, 05 Mar 2008 08:57:31 +0000, Jason Rumney said: > YAMAMOTO Mitsuharu wrote: >> 2008-03-05 Jason Rumney * fileio.c >> (Fexpand_file_name): Decode home directory names. >> (Fsubstitute_in_file_name): Decode substituted variables. >> >> But I'd strongly suggest to revert this changes at this timing of >> pretest for upcoming Emacs 22.2. > It fixes a serious bug. Users with non-ASCII names in their user > names get strange behaviour of filename expansion. I know, but your patch has a serious problem and leads to regression. >> First, some coding systems are not ready until some .elc files get >> loaded (a chicken-and-egg problem). >> > It should not present a chicken and egg problem, as no files are > loaded during bootstrap that require expansion of ~ or environment > variables. I meant the startup of the dumped executable. Users may set EMACS_LOAD_PATH and so on. >> Second, as DECODE_FILE causes GC and string compaction in general, >> some variables such as `nm' in Fexpand_file_name may not point to >> valid data after that. > This is a problem on some systems that still do not support stack > marking for GC protection of such variables. But I think this bug is > important enough to fix those problems rather than revert the patch. Relocation of string data caused by GC has nothing to do with (semi-obsolete) GCPROs. Believe me, it causes a real problem. >> You may also want to see a related patch in >> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html >> > Was there a problem with that patch? Why was it not installed at the time? Because no expert in this area made a response about the patch. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From unknown Sat Aug 16 16:14:25 2025 X-Loop: don@donarmstrong.com Subject: bug#38: No coding system used for environment variables Reply-To: Jason Rumney , 38@debbugs.gnu.org Resent-From: Jason Rumney Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 05 Mar 2008 10:20:03 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 38 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 38-submit@emacsbugs.donarmstrong.com id=B38.120471193218610 (code B ref 38); Wed, 05 Mar 2008 10:20:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=0.1 required=4.0 tests=AWL,MURPHY_DRUGS_REL8, SPF_HELO_PASS autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 38) by emacsbugs.donarmstrong.com; 5 Mar 2008 10:12:12 +0000 Received: from mk-outboundfilter-4.mail.uk.tiscali.com (mk-outboundfilter-4.mail.uk.tiscali.com [212.74.114.32]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m25AC5CK018604 for <38@emacsbugs.donarmstrong.com>; Wed, 5 Mar 2008 02:12:07 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAYBzkdTQxds/2dsb2JhbAAIq2w X-IronPort-AV: E=McAfee;i="5200,2160,5244"; a="19622080" X-IP-Direction: OUT Received: from i-83-67-23-108.freedom2surf.net (HELO [127.0.0.1]) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2008 10:11:47 +0000 Message-ID: <47CE71DE.7070002@gnu.org> Date: Wed, 05 Mar 2008 10:11:42 +0000 From: Jason Rumney User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: YAMAMOTO Mitsuharu CC: =?UTF-8?Q?G=C3=B6ran?= Uddeborg , bug-gnu-emacs@gnu.org, 38@debbugs.gnu.org References: <200802212140.m1LLeebW008878@freddi.uddeborg.se> <47CDEBFD.1060603@gnu.org> <47CE607B.1000708@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit YAMAMOTO Mitsuharu wrote: >> Was there a problem with that patch? Why was it not installed at the time? >> > > Because no expert in this area made a response about the patch. > OK, I reverted my change. I'll let Chong and Stefan decide whether to fix the bug with your safer patch now (and a similar patch for Fsubstitute_in_file_name) or release 22.2 with this as a known bug. From unknown Sat Aug 16 16:14:25 2025 X-Loop: don@donarmstrong.com Subject: bug#38: No coding system used for environment variables Reply-To: Andreas Schwab , 38@debbugs.gnu.org Resent-From: Andreas Schwab Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 05 Mar 2008 10:45:05 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 38 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 38-submit@emacsbugs.donarmstrong.com id=B38.120471331621283 (code B ref 38); Wed, 05 Mar 2008 10:45:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-4.0 required=4.0 tests=MURPHY_DRUGS_REL8, RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 38) by emacsbugs.donarmstrong.com; 5 Mar 2008 10:35:16 +0000 Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m25AZ7io021149 for <38@emacsbugs.donarmstrong.com>; Wed, 5 Mar 2008 02:35:09 -0800 Received: from Relay2.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 26DD6396DB; Wed, 5 Mar 2008 11:34:55 +0100 (CET) From: Andreas Schwab To: Jason Rumney Cc: YAMAMOTO Mitsuharu , bug-gnu-emacs@gnu.org, 38@debbugs.gnu.org, =?UTF-8?Q?G=C3=B6ran?= Uddeborg References: <200802212140.m1LLeebW008878@freddi.uddeborg.se> <47CDEBFD.1060603@gnu.org> <47CE607B.1000708@gnu.org> X-Yow: On SECOND thought, maybe I'll heat up some BAKED BEANS and watch REGIS PHILBIN.. It's GREAT to be ALIVE!! Date: Wed, 05 Mar 2008 11:34:53 +0100 In-Reply-To: <47CE607B.1000708@gnu.org> (Jason Rumney's message of "Wed\, 05 Mar 2008 08\:57\:31 +0000") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jason Rumney writes: > YAMAMOTO Mitsuharu wrote: >> Second, as DECODE_FILE causes GC and string compaction in general, >> some variables such as `nm' in Fexpand_file_name may not point to >> valid data after that. > > This is a problem on some systems that still do not support stack marking > for GC protection of such variables. But I think this bug is important > enough to fix those problems rather than revert the patch. Only Lisp_Object variables are protected. Failing to protect non-Lisp_Object pointers can result in crashes. A crash is always the worst possible problem. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sat Aug 16 16:14:25 2025 X-Loop: don@donarmstrong.com Subject: bug#38: No coding system used for environment variables Reply-To: YAMAMOTO Mitsuharu , 38@debbugs.gnu.org Resent-From: YAMAMOTO Mitsuharu Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 05 Mar 2008 11:10:04 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 38 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 38-submit@emacsbugs.donarmstrong.com id=B38.120471484024821 (code B ref 38); Wed, 05 Mar 2008 11:10:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=0.0 required=4.0 tests=MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 38) by emacsbugs.donarmstrong.com; 5 Mar 2008 11:00:40 +0000 Received: from mathmail.math.s.chiba-u.ac.jp (mathmail.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m25B0aiu024815 for <38@emacsbugs.donarmstrong.com>; Wed, 5 Mar 2008 03:00:37 -0800 Received: from localhost (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 86E5F2C40; Wed, 5 Mar 2008 20:00:22 +0900 (JST) Date: Wed, 05 Mar 2008 20:00:15 +0900 (JST) Message-Id: <20080305.200015.10931251.mituharu@math.s.chiba-u.ac.jp> To: jasonr@gnu.org Cc: goeran@uddeborg.se, bug-gnu-emacs@gnu.org, 38@debbugs.gnu.org From: YAMAMOTO Mitsuharu In-Reply-To: <47CE71DE.7070002@gnu.org> References: <47CE607B.1000708@gnu.org> <47CE71DE.7070002@gnu.org> X-Mailer: Mew version 3.3 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> On Wed, 05 Mar 2008 10:11:42 +0000, Jason Rumney said: >>> Was there a problem with that patch? Why was it not installed at >>> the time? >> >> Because no expert in this area made a response about the patch. > OK, I reverted my change. Thanks. > I'll let Chong and Stefan decide whether to fix the bug with your > safer patch now (and a similar patch for Fsubstitute_in_file_name) > or release 22.2 with this as a known bug. I understand the bug is annoying on certain environments, but I would like to defer any kinds of fixes for this bug to later versions, as the fixes involve nontrivial issues and may affect in unexpected ways. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp From unknown Sat Aug 16 16:14:25 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) X-Loop: don@donarmstrong.com From: help-debbugs@gnu.org (Emacs bug Tracking System) To: Jason Rumney Subject: bug#38 closed by Stefan Monnier (Re: No coding system used for environment variables) Message-ID: References: <47CDE82D.2020302@gnu.org> X-Emacs-PR-Message: they-closed 38 X-Emacs-PR-Package: emacs Reply-To: 38@debbugs.gnu.org Content-Type: multipart/mixed; boundary="----------=_1204734903-5388-1" This is a multi-part message in MIME format... ------------=_1204734903-5388-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This is an automatic notification regarding your bug report which was filed against the emacs package: #38: No coding system used for environment variables It has been closed by Stefan Monnier . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Stefan Monnier by replying to this email. --=20 38: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D38 Emacs Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1204734903-5388-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit >From monnier@iro.umontreal.ca Wed Mar 5 08:26:25 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=AWL,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 38-done) by emacsbugs.donarmstrong.com; 5 Mar 2008 16:26:25 +0000 Received: from ironport2-out.pppoe.ca (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m25GQHL6004728 for <38-done@emacsbugs.donarmstrong.com>; Wed, 5 Mar 2008 08:26:19 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGdYzkfO+LKX/2dsb2JhbACrcIEC X-IronPort-AV: E=Sophos;i="4.25,451,1199682000"; d="scan'208";a="15618902" Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 05 Mar 2008 11:26:00 -0500 Received: from pastel.home ([206.248.178.151]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id LTF04500; Wed, 05 Mar 2008 11:26:00 -0500 Received: by pastel.home (Postfix, from userid 20848) id 069BF8359; Wed, 5 Mar 2008 11:26:00 -0500 (EST) From: Stefan Monnier To: YAMAMOTO Mitsuharu Cc: Jason Rumney , bug-gnu-emacs@gnu.org, =?iso-8859-1?Q?G=1FFFFFFFran?= Uddeborg , 38-done@debbugs.gnu.org Subject: Re: No coding system used for environment variables Message-ID: References: <200802212140.m1LLeebW008878@freddi.uddeborg.se> <47CDEBFD.1060603@gnu.org> Date: Wed, 05 Mar 2008 11:25:59 -0500 In-Reply-To: (YAMAMOTO Mitsuharu's message of "Wed, 05 Mar 2008 11:22:03 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > But I'd strongly suggest to revert this changes at this timing of > pretest for upcoming Emacs 22.2. First, some coding systems are not > ready until some .elc files get loaded (a chicken-and-egg problem). > Second, as DECODE_FILE causes GC and string compaction in general, > some variables such as `nm' in Fexpand_file_name may not point to > valid data after that. You may also want to see a related patch in > http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html How 'bout installing this change on the trunk? Stefan ------------=_1204734903-5388-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit >From jasonr@gnu.org Tue Mar 4 16:24:39 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,IMPRONONCABLE_2, SPF_HELO_PASS autolearn=no version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 5 Mar 2008 00:24:40 +0000 Received: from mk-outboundfilter-4.mail.uk.tiscali.com (mk-outboundfilter-4.mail.uk.tiscali.com [212.74.114.32]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m250OXmC003617 for ; Tue, 4 Mar 2008 16:24:35 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALV2zUdTQxds/2dsb2JhbAAIrj8 X-IronPort-AV: E=McAfee;i="5200,2160,5244"; a="19420566" X-IronPort-AV: E=Sophos;i="4.25,444,1199664000"; d="scan'208";a="19420566" X-IP-Direction: OUT Received: from i-83-67-23-108.freedom2surf.net (HELO [127.0.0.1]) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2008 00:24:15 +0000 Message-ID: <47CDE82D.2020302@gnu.org> Date: Wed, 05 Mar 2008 00:24:13 +0000 From: Jason Rumney User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: submit@debbugs.gnu.org Subject: No coding system used for environment variables Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit -------- Original Message -------- Subject: No coding system used for environment variables Date: Thu, 21 Feb 2008 22:40:40 +0100 From: Göran Uddeborg 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 ö 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 ö. (expand-file-name "") "/home/göran" Ok too. (expand-file-name "~") "/home/g\303\266ran" Here the octal codes for a UTF-8 encoded ö is shown instead of the ö 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 ö. 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 ö in the file name is ok. The ö 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: ? M-< C-n C-k C-k C-y p C-j C-x 4 C-f . e m C-s v m - s p o o M-< C-x C-f . v m C-g C-x C-f ~ / . v m 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 q 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 C-x M q q C-x M n n n n n n n M-< C-s S E C C-a SPC C-x C-f ~ / N C-x c C-a C-k r p m g r e p SPC l h a ! d C-u C-u C-u 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 u p d 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 = C-c C-c SPC SPC n s I q d SPC M-x r e p o r 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 ------------=_1204734903-5388-1-- From unknown Sat Aug 16 16:14:25 2025 X-Loop: don@donarmstrong.com Subject: bug#38: No coding system used for environment variables Reply-To: Chong Yidong , 38@debbugs.gnu.org Resent-From: Chong Yidong Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 24 Jul 2008 00:10:05 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 38 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 38-submit@emacsbugs.donarmstrong.com id=B38.121685764125492 (code B ref 38); Thu, 24 Jul 2008 00:10:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,BAYES_00, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 38) by emacsbugs.donarmstrong.com; 24 Jul 2008 00:00:41 +0000 Received: from cyd (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m6O00WZG025132 for <38@emacsbugs.donarmstrong.com>; Wed, 23 Jul 2008 17:00:33 -0700 Received: by cyd (Postfix, from userid 1000) id 6185F57E32C; Wed, 23 Jul 2008 20:01:56 -0400 (EDT) From: Chong Yidong To: YAMAMOTO Mitsuharu , Jason Rumney Cc: 38@debbugs.gnu.org, emacs-devel@gnu.org Date: Wed, 23 Jul 2008 20:01:54 -0400 Message-ID: <87y73s1765.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > It seems there is no coding system applied to values of environment > variables. What's the current situation with this bug? Jason's patch was reverted, but nothing else seems to have been done after that. 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 noticed that the patch posted at http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html has not been checked into the trunk either. From unknown Sat Aug 16 16:14:25 2025 X-Loop: don@donarmstrong.com Subject: bug#38: No coding system used for environment variables Reply-To: Jason Rumney , 38@debbugs.gnu.org Resent-From: Jason Rumney Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 24 Jul 2008 00:20:04 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 38 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 38-submit@emacsbugs.donarmstrong.com id=B38.121685823728560 (code B ref 38); Thu, 24 Jul 2008 00:20:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-4.0 required=4.0 tests=AWL,BAYES_00, MURPHY_DRUGS_REL8,SPF_HELO_PASS autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 38) by emacsbugs.donarmstrong.com; 24 Jul 2008 00:10:37 +0000 Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m6O0AXgB028553 for <38@emacsbugs.donarmstrong.com>; Wed, 23 Jul 2008 17:10:34 -0700 X-Trace: 61217636/mk-outboundfilter-5.mail.uk.tiscali.com/F2S/$F2S-ACCEPTED/f2s-freedom2Surf-customers/83.67.23.108 X-SBRS: None X-RemoteIP: 83.67.23.108 X-IP-MAIL-FROM: jasonr@gnu.org X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EADhlh0hTQxds/2dsb2JhbACBWrFU X-IronPort-AV: E=Sophos;i="4.31,241,1215385200"; d="scan'208";a="61217636" X-IP-Direction: IN Received: from i-83-67-23-108.freedom2surf.net (HELO wanchan.jasonrumney.net) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP; 24 Jul 2008 01:10:27 +0100 Received: from [192.168.249.27] (chiko.jasonrumney.net [192.168.249.27]) by wanchan.jasonrumney.net (Postfix) with ESMTP id D5CD769; Thu, 24 Jul 2008 01:10:40 +0100 (BST) Message-ID: <4887C867.3060602@gnu.org> Date: Thu, 24 Jul 2008 01:10:15 +0100 From: Jason Rumney User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Chong Yidong CC: YAMAMOTO Mitsuharu , 38@debbugs.gnu.org, emacs-devel@gnu.org References: <87y73s1765.fsf@stupidchicken.com> In-Reply-To: <87y73s1765.fsf@stupidchicken.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=8086879D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Chong Yidong wrote: >> It seems there is no coding system applied to values of environment >> variables. > > What's the current situation with this bug? Jason's patch was reverted, > but nothing else seems to have been done after that. > > 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 > I noticed that the patch posted at > > http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html > > has not been checked into the trunk either. I think the bug reported there is the same as #93, which is fixed in the trunk, but not the branch AFAIK. From unknown Sat Aug 16 16:14:25 2025 X-Loop: don@donarmstrong.com Subject: bug#38: No coding system used for environment variables Reply-To: Chong Yidong , 38@debbugs.gnu.org Resent-From: Chong Yidong Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 24 Jul 2008 00:35:03 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 38 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by 38-submit@emacsbugs.donarmstrong.com id=B38.121685934132161 (code B ref 38); Thu, 24 Jul 2008 00:35:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,BAYES_00, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 38) by emacsbugs.donarmstrong.com; 24 Jul 2008 00:29:01 +0000 Received: from cyd (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m6O0SvMX032154 for <38@emacsbugs.donarmstrong.com>; Wed, 23 Jul 2008 17:28:59 -0700 Received: by cyd (Postfix, from userid 1000) id 06A5857E32C; Wed, 23 Jul 2008 20:30:21 -0400 (EDT) From: Chong Yidong To: Jason Rumney Cc: YAMAMOTO Mitsuharu , 38@debbugs.gnu.org, emacs-devel@gnu.org References: <87y73s1765.fsf@stupidchicken.com> <4887C867.3060602@gnu.org> Date: Wed, 23 Jul 2008 20:30:20 -0400 In-Reply-To: <4887C867.3060602@gnu.org> (Jason Rumney's message of "Thu, 24 Jul 2008 01:10:15 +0100") Message-ID: <87bq0o6s4j.fsf@stupidchicken.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Jason Rumney 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 noticed that the patch posted at >> >> http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-05/msg00115.html >> >> has not been checked into the trunk either. > > I think the bug reported there is the same as #93, which is fixed in the > trunk, but not the branch AFAIK. Could you port this fix to the branch? Thanks. From unknown Sat Aug 16 16:14:25 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.420 (Entity 5.420) X-Loop: owner@emacsbugs.donarmstrong.com From: help-debbugs@gnu.org (Emacs bug Tracking System) To: Jason Rumney Subject: bug#38 closed by Jason Rumney (bug#38: Re: No coding system used for environment variables) Message-ID: References: <49C8ECD0.2090706@gnu.org> <47CDE82D.2020302@gnu.org> X-Emacs-PR-Message: they-closed 38 X-Emacs-PR-Package: emacs Reply-To: 38@debbugs.gnu.org Date: Tue, 24 Mar 2009 14:30:05 +0000 Content-Type: multipart/mixed; boundary="----------=_1237905005-2895-1" This is a multi-part message in MIME format... ------------=_1237905005-2895-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This is an automatic notification regarding your bug report which was filed against the emacs package: #38: No coding system used for environment variables It has been closed by Jason Rumney . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Jason Rumney by replying to this email. --=20 38: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D38 Emacs Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1237905005-2895-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 38-done) by emacsbugs.donarmstrong.com; 24 Mar 2009 14:23:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n2OENfq9001379 for <38-done@emacsbugs.donarmstrong.com>; Tue, 24 Mar 2009 07:23:42 -0700 Received: by ti-out-0910.google.com with SMTP id u3so2391697tia.1 for <38-done@emacsbugs.donarmstrong.com>; Tue, 24 Mar 2009 07:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ocrGxj88bYVsk+8w3EfpM6rwkDUYEgYDcVdGnsp5W4I=; b=ScpERccsmqJ9WzsGMuRaNA3/lYPTY0I21mcQHaorAp41RDFK16D/ECDFBkMhLjnjbH 3CsaitA2naq/+K/SHL+BoeMOX+IvqthcI963PUCA+dzxy4oaQxhcMq/qUFn5Q9EK5g/+ dvQjW9dvArQHmpWKfLQjqFJQP4bcVaSQ48kTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=t0y+LOVg64Hy/rIXCcx3TG8ddsMWp+rU0kN26ZTv+lxv9M52QD9fhmPfaK60nJev1i WiI1BJb55/qYEAgt0fgtBy9mUIhgNvhT1HVBlikESrywf1AfY3NOQHBfBvlsY2TeR+f+ Z3phDFtC1n/DPVODVXepdPMQ4JO58WDe6K1LU= Received: by 10.110.40.8 with SMTP id n8mr12926376tin.28.1237904619911; Tue, 24 Mar 2009 07:23:39 -0700 (PDT) Received: from ?192.168.249.26? ([118.100.163.214]) by mx.google.com with ESMTPS id d1sm27662tid.34.2009.03.24.07.23.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Mar 2009 07:23:39 -0700 (PDT) Sender: Jason Rumney Message-ID: <49C8ECD0.2090706@gnu.org> Date: Tue, 24 Mar 2009 22:23:12 +0800 From: Jason Rumney User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Chong Yidong CC: YAMAMOTO Mitsuharu , 38-done@debbugs.gnu.org Subject: bug#38: Re: No coding system used for environment variables References: <87y73s1765.fsf@stupidchicken.com> <4887C867.3060602@gnu.org> <87bq0o6s4j.fsf@stupidchicken.com> In-Reply-To: <87bq0o6s4j.fsf@stupidchicken.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Chong Yidong wrote: > Jason Rumney 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. ------------=_1237905005-2895-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit >From jasonr@gnu.org Tue Mar 4 16:24:39 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Status: No, score=1.1 required=4.0 tests=FOURLA,IMPRONONCABLE_2, SPF_HELO_PASS autolearn=no version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 5 Mar 2008 00:24:40 +0000 Received: from mk-outboundfilter-4.mail.uk.tiscali.com (mk-outboundfilter-4.mail.uk.tiscali.com [212.74.114.32]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m250OXmC003617 for ; Tue, 4 Mar 2008 16:24:35 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALV2zUdTQxds/2dsb2JhbAAIrj8 X-IronPort-AV: E=McAfee;i="5200,2160,5244"; a="19420566" X-IronPort-AV: E=Sophos;i="4.25,444,1199664000"; d="scan'208";a="19420566" X-IP-Direction: OUT Received: from i-83-67-23-108.freedom2surf.net (HELO [127.0.0.1]) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2008 00:24:15 +0000 Message-ID: <47CDE82D.2020302@gnu.org> Date: Wed, 05 Mar 2008 00:24:13 +0000 From: Jason Rumney User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: submit@debbugs.gnu.org Subject: No coding system used for environment variables Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit -------- Original Message -------- Subject: No coding system used for environment variables Date: Thu, 21 Feb 2008 22:40:40 +0100 From: Göran Uddeborg 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 ö 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 ö. (expand-file-name "") "/home/göran" Ok too. (expand-file-name "~") "/home/g\303\266ran" Here the octal codes for a UTF-8 encoded ö is shown instead of the ö 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 ö. 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 ö in the file name is ok. The ö 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: ? M-< C-n C-k C-k C-y p C-j C-x 4 C-f . e m C-s v m - s p o o M-< C-x C-f . v m C-g C-x C-f ~ / . v m 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 q 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 C-x M q q C-x M n n n n n n n M-< C-s S E C C-a SPC C-x C-f ~ / N C-x c C-a C-k r p m g r e p SPC l h a ! d C-u C-u C-u 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 u p d 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 = C-c C-c SPC SPC n s I q d SPC M-x r e p o r 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 ------------=_1237905005-2895-1--