From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 09 12:15:32 2012 Received: (at submit) by debbugs.gnu.org; 9 Mar 2012 17:15:32 +0000 Received: from localhost ([127.0.0.1]:40783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S63Pe-0000Ox-SO for submit@debbugs.gnu.org; Fri, 09 Mar 2012 12:15:32 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37458) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S5xcU-0007nw-NK for submit@debbugs.gnu.org; Fri, 09 Mar 2012 06:04:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5xbB-0005fr-5K for submit@debbugs.gnu.org; Fri, 09 Mar 2012 06:03:27 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:54295) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5xbB-0005fY-1R for submit@debbugs.gnu.org; Fri, 09 Mar 2012 06:03:01 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5xb3-0003i4-Q3 for bug-gnu-emacs@gnu.org; Fri, 09 Mar 2012 06:03:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S5xab-0005ZD-N5 for bug-gnu-emacs@gnu.org; Fri, 09 Mar 2012 06:02:52 -0500 Received: from seluib4vp34.perspektivbredband.net ([81.186.254.26]:35180) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S5xab-0005W1-AP for bug-gnu-emacs@gnu.org; Fri, 09 Mar 2012 06:02:25 -0500 Received: from spc2 (hd5b913e4.seluldx.dyn.perspektivbredband.net [213.185.19.228]) by seluib4vp34.perspektivbredband.net (Postfix) with SMTP id 2F7FF60556 for ; Fri, 9 Mar 2012 12:01:58 +0100 (CET) Message-ID: <91BFD8A43A0C4F29ADF1BB30E3861DAD@spc2> From: "Bo Johansson" To: Subject: 23.4; Variable init_environment incorrectly set Date: Fri, 9 Mar 2012 12:01:53 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01CCFDEC.6B17E8E0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 09 Mar 2012 12:15:29 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Det här är ett flerdelat meddelande i MIME-format. ------=_NextPart_000_0025_01CCFDEC.6B17E8E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hej! --------------------------- Background I am used to "live" in Emacs and want to get the same result doing = something from within Emacs as doing it from a Windows command prompt. For example (compile "dmake" nil) in Emacs and executing dmake in a = Windows command window should give the same result. --------------------------- Example of Problems Emacs replaces the environment variable SHELL at start up in Windows to = something like "C:/Program Files (x86)/GNU Emacs 23.4/bin/cmdproxy.exe". = Processes started by Emacs will inherit this value. Many utilities uses SHELL. One example is: With " ... cmdproxy.exe" as = value of SHELL dmake is configured to use a Kornshell compatible shell. --------------------------- Solution ideas A long time goal should be to avoid changing the environment variable = within Emacs. Emacs should (internally) at least not change the value of = SHELL. A short time solution is to make the initial environment variable = available as stated in = http://www.gnu.org/software/emacs/manual/html_node/emacs/Environment.html= : "The variable initial-environment stores the initial environment = inherited by Emacs". This make it possible in emacs-git/lisp/progmodes/compile.el:1479 (defun compilation-start (command &optional mode name-function = highlight-regexp) to use the variable compilation-environment to temporary override the in = emacs internal used environment variables. In emacs-git/lisp/progmodes/simple.el:2088 (defun shell-command (command &optional output-buffer error-buffer) the corresponding possibility is however not available. --------------------------- Description of the Bug Below follows a list of steps done at start up. The problem is that step = 2) changes the environment variables before step 4) sets the variable = initial_environment. 1) The function init_environment is called emacs-git/src/emacs.c:1416 #ifdef MSDOS /* Call early 'cause init_environment needs it. */ init_dosfns (); /* Set defaults for several environment variables. */ if (initialized) init_environment (argc, argv, skip_args); else tzset (); #endif /* MSDOS */ #ifdef WINDOWSNT globals_of_w32 (); /* Initialize environment from registry settings. */ init_environment (argv); init_ntproc (); /* must precede init_editfns. */ #endif 2) The function init_environment changes the environment variables T:/emacs-git/src/w32.c:1528:init_environment (char ** argv) Do a lot of changes to the environment variables. 3) The function set_initial_environment is called to save the = "initial_environment" emacs-git/src/emacs.c:1440 /* Initialize and GC-protect Vinitial_environment and Vprocess_environment before set_initial_environment fills them in. */ if (!initialized) syms_of_callproc (); /* egetenv is a pretty low-level facility, which may get called in many circumstances; it seems flimsy to put off initializing it until calling init_callproc. Do not do it when dumping. */ if (initialized || ((strcmp (argv[argc-1], "dump") !=3D 0 && strcmp (argv[argc-1], "bootstrap") !=3D 0))) set_initial_environment (); 4) The variable initial_environment is set by set_initial_environment emacs-git/src/callproc.c:1616 set_initial_environment (void) emacs-git/src/callproc.c:1624 Vinitial_environment =3D Fcopy_sequence (Vprocess_environment); ----------------------------------------------------- In GNU Emacs 23.4.1 (i386-mingw-nt6.1.7601) of 2012-02-04 on MARVIN Windowing system distributor `Microsoft Corp.', version 6.1.7601 configured using `configure --with-gcc (4.4) --cflags = -ID:/devel/emacs/libs/libXpm-3.5.8/include = -ID:/devel/emacs/libs/libXpm-3.5.8/src = -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include = -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include = -ID:/devel/emacs/libs/giflib-4.1.4-1/include = -ID:/devel/emacs/libs/jpeg-6b-4/include = -ID:/devel/emacs/libs/tiff-3.8.2-1/include' 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: SVE value of $XMODIFIERS: nil locale-coding-system: cp1252 default enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: diff-auto-refine-mode: t shell-dirtrack-mode: t delete-selection-mode: t show-paren-mode: t cua-mode: t tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t auto-fill-mode: t Recent input: x r e p o r Recent messages: Loading cua-base...done Loading paren...done userDotEmacs Done Finding all versions of R on your system... Sorry, no version of R could be found on your system. Making completion list... Load-path shadows: None found. Features: (shadow sort mail-extr message ecomplete rfc822 mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc time-date mm-util mail-prsvr gmm-utils mailheader canlock sha1 hex-util hashcash mail-utils emacsbug help-mode view psvn byte-opt warnings bytecomp byte-compile derived edmacro kmacro wid-edit log-edit pcvs-util add-log diff-mode easy-mmode pp elp ediff-merg ediff-diff ediff-wind ediff-mult ediff-help ediff-init ediff-util dired tex-mik preview-latex tex-site auto-loads ess-eldoc ess-toolbar ess-mouse mouseme thingatpt browse-url ess-menu ess-swv ess-noweb noweb-font-lock-mode ess-bugs-l essd-els ess-sas-d ess-sas-l ess-sas-a executable shell ess-arc-d ess-vst-d ess-xls-d ess-lsp-l ess-sta-d ess-sta-l cc-vars cc-defs make-regexp ess-sp6w-d ess-sp4-d ess-sp3-d ess-r-d ess-r-args assoc ess-s-l ess-inf ess-utils comint ring ess-mode noweb-mode ess ess-custom regexp-opt ess-compat ess-site htmlize-view easymenu w32-winprint htmlize cl cl-19 delsel server advice help-fns advice-preload paren cua-base cus-start cus-load tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces cus-face files text-properties overlay md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process multi-tty emacs) ------=_NextPart_000_0025_01CCFDEC.6B17E8E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hej!
 
--------------------------- Background
I am used to "live" in Emacs and want to get the same result doing=20 something from within Emacs as doing it from a Windows command = prompt.
For example (compile "dmake" nil) in Emacs and executing dmake in a = Windows=20 command window should give the same result.
 
--------------------------- Example of Problems
Emacs replaces the environment variable SHELL at start up in = Windows to=20 something like "C:/Program Files (x86)/GNU Emacs 23.4/bin/cmdproxy.exe". = Processes started by Emacs will inherit this value.
 
Many utilities uses SHELL. One example is:  With " ... = cmdproxy.exe"=20 as value of SHELL dmake is configured to use a Kornshell compatible = shell.
 
--------------------------- Solution ideas
A long time goal should be to avoid changing the environment = variable=20 within Emacs. Emacs should (internally) at least not change the value of = SHELL.
 
A short time solution is to make the initial environment variable = available=20 as stated in http://www.gnu.org/software/emacs/manual/html_node/emacs/Envir= onment.html:=20 "The variable initial-environment stores the initial environment = inherited by=20 Emacs".
 
This make it possible in
emacs-git/lisp/progmodes/compile.el:1479
(defun compilation-start (command &optional mode name-function=20 highlight-regexp)
to use the variable compilation-environment to temporary override = the in=20 emacs internal used environment variables.
 
In emacs-git/lisp/progmodes/simple.el:2088
(defun shell-command (command &optional output-buffer=20 error-buffer)
the corresponding possibility is however not available.
 
--------------------------- Description of the Bug
Below follows a list of steps done at start up. The problem is that = step 2)=20 changes the environment variables before step 4) sets the variable=20 initial_environment.
 
1) The function init_environment is called
 
emacs-git/src/emacs.c:1416
#ifdef MSDOS
  /* Call early 'cause init_environment needs it.  = */
  init_dosfns ();
  /* Set defaults for several environment variables.  = */
  if (initialized)
    init_environment (argc, argv, skip_args);
  else
    tzset ();
#endif /* MSDOS */
 
#ifdef WINDOWSNT
  globals_of_w32 ();
  /* Initialize environment from registry settings.  = */
  init_environment (argv);
  init_ntproc ();    /* must precede=20 init_editfns.  */
#endif
 
2) The function init_environment changes the environment = variables
 
T:/emacs-git/src/w32.c:1528:init_environment (char ** argv)
Do a lot of changes to the environment variables.
 
3) The function set_initial_environment is called to save the=20 "initial_environment"
 
emacs-git/src/emacs.c:1440
  /* Initialize and GC-protect Vinitial_environment and
     Vprocess_environment before=20 set_initial_environment fills them
     in.  */
  if (!initialized)
    syms_of_callproc ();
  /* egetenv is a pretty low-level facility, which may get = called=20 in
     many circumstances; it seems flimsy to put = off=20 initializing it
     until calling init_callproc.  Do not = do it=20 when dumping.  */
  if (initialized || ((strcmp (argv[argc-1], "dump") !=3D = 0
           &n= bsp;  =20 && strcmp (argv[argc-1], "bootstrap") !=3D 0)))
    set_initial_environment ();
 
4) The variable initial_environment is set by = set_initial_environment
 
emacs-git/src/callproc.c:1616
set_initial_environment (void)
emacs-git/src/callproc.c:1624
Vinitial_environment =3D Fcopy_sequence = (Vprocess_environment);
 
 
-----------------------------------------------------
In GNU Emacs 23.4.1 (i386-mingw-nt6.1.7601)
of 2012-02-04 on MARVIN
Windowing system distributor `Microsoft Corp.', version = 6.1.7601
configured using `configure --with-gcc (4.4) --cflags=20 -ID:/devel/emacs/libs/libXpm-3.5.8/include=20 -ID:/devel/emacs/libs/libXpm-3.5.8/src=20 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include=20 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include=20 -ID:/devel/emacs/libs/giflib-4.1.4-1/include=20 -ID:/devel/emacs/libs/jpeg-6b-4/include=20 -ID:/devel/emacs/libs/tiff-3.8.2-1/include'
 
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: SVE
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t
 
Major mode: Lisp Interaction
 
Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  delete-selection-mode: t
  show-paren-mode: t
  cua-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-fill-mode: t
 
Recent input:
<escape> x r e p o <tab> r <tab> = <return>
 
Recent messages:
Loading cua-base...done
Loading paren...done
userDotEmacs Done
Finding all versions of R on your system...
Sorry, no version of R could be found on your system.
Making completion list...
 
Load-path shadows:
None found.
 
Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse=20 rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util = netrc
time-date mm-util mail-prsvr gmm-utils mailheader canlock sha1=20 hex-util
hashcash mail-utils emacsbug help-mode view psvn byte-opt = warnings
bytecomp byte-compile derived edmacro kmacro wid-edit log-edit=20 pcvs-util
add-log diff-mode easy-mmode pp elp ediff-merg ediff-diff = ediff-wind
ediff-mult ediff-help ediff-init ediff-util dired tex-mik=20 preview-latex
tex-site auto-loads ess-eldoc ess-toolbar ess-mouse mouseme = thingatpt
browse-url ess-menu ess-swv ess-noweb noweb-font-lock-mode = ess-bugs-l
essd-els ess-sas-d ess-sas-l ess-sas-a executable shell = ess-arc-d
ess-vst-d ess-xls-d ess-lsp-l ess-sta-d ess-sta-l cc-vars = cc-defs
make-regexp ess-sp6w-d ess-sp4-d ess-sp3-d ess-r-d ess-r-args = assoc
ess-s-l ess-inf ess-utils comint ring ess-mode noweb-mode ess=20 ess-custom
regexp-opt ess-compat ess-site htmlize-view easymenu = w32-winprint
htmlize cl cl-19 delsel server advice help-fns advice-preload = paren
cua-base cus-start cus-load tooltip ediff-hook vc-hooks=20 lisp-float-type
mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd=20 fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer=20 select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu = font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan = thai
tai-viet lao korean japanese hebrew greek romanian slovak czech=20 european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook=20 help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule = custom
widget hashtable-print-readable backquote make-network-process=20 multi-tty
emacs)
------=_NextPart_000_0025_01CCFDEC.6B17E8E0-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 23 03:01:44 2012 Received: (at 10980) by debbugs.gnu.org; 23 Mar 2012 07:01:44 +0000 Received: from localhost ([127.0.0.1]:34033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SAyVM-0007Ec-17 for submit@debbugs.gnu.org; Fri, 23 Mar 2012 03:01:44 -0400 Received: from seluib4vp34.perspektivbredband.net ([81.186.254.26]:41685) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SAyVH-0007ES-4H for 10980@debbugs.gnu.org; Fri, 23 Mar 2012 03:01:40 -0400 Received: from spc2 (hd5b913e4.seluldx.dyn.perspektivbredband.net [213.185.19.228]) by seluib4vp34.perspektivbredband.net (Postfix) with SMTP id 3463B63990 for <10980@debbugs.gnu.org>; Fri, 23 Mar 2012 07:30:46 +0100 (CET) Message-ID: From: "Bo Johansson" To: <10980@debbugs.gnu.org> Subject: bug#10980: 23.4; Variable initial-environment incorrectly set Date: Fri, 23 Mar 2012 07:30:42 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01CD08C6.DA562D40" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10980 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Det här är ett flerdelat meddelande i MIME-format. ------=_NextPart_000_0017_01CD08C6.DA562D40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the mail topic is =E2=80=9Cinit_environment=E2=80=9D corrected to = =E2=80=9Cinitial-environment=E2=80=9D. Summary of bug: On Windows the Emacs variable initial-environment is NOT set according = to the documentation: "The variable initial-environment stores the initial environment = inherited by Emacs". ------=_NextPart_000_0017_01CD08C6.DA562D40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the mail topic is =E2=80=9Cinit_environment=E2=80=9D corrected = to =20 =E2=80=9Cinitial-environment=E2=80=9D.
 
Summary of bug:
 
On Windows the Emacs variable initial-environment is NOT set = according to=20 the documentation:
"The variable initial-environment stores the initial environment = inherited=20 by Emacs".
------=_NextPart_000_0017_01CD08C6.DA562D40-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 23 12:38:14 2012 Received: (at 10980) by debbugs.gnu.org; 23 Mar 2012 16:38:14 +0000 Received: from localhost ([127.0.0.1]:35590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SB7V7-0004xx-Kb for submit@debbugs.gnu.org; Fri, 23 Mar 2012 12:38:14 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:43524) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SB7Ur-0004xH-DH for 10980@debbugs.gnu.org; Fri, 23 Mar 2012 12:38:04 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M1C00800I3D5A00@a-mtaout22.012.net.il> for 10980@debbugs.gnu.org; Fri, 23 Mar 2012 18:06:50 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.241.151]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1C007N4I3DF3H0@a-mtaout22.012.net.il>; Fri, 23 Mar 2012 18:06:50 +0200 (IST) Date: Fri, 23 Mar 2012 18:06:57 +0200 From: Eli Zaretskii Subject: Re: bug#10980: 23.4; Variable initial-environment incorrectly set In-reply-to: X-012-Sender: halo1@inter.net.il To: Bo Johansson Message-id: <83d383uwri.fsf@gnu.org> References: <91BFD8A43A0C4F29ADF1BB30E3861DAD@spc2> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 10980 Cc: 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Bo Johansson" > Date: Fri, 23 Mar 2012 07:30:42 +0100 > > On Windows the Emacs variable initial-environment is NOT set according to the documentation: > "The variable initial-environment stores the initial environment inherited by Emacs". I'm sorry, I'm not sure I understand the essence of your report. What exactly would you like the documentation to say that it doesn't say now? Or, to put it differently, what in the way initial-environment is set on Windows contradicts the documentation? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 23 16:51:59 2012 Received: (at 10980) by debbugs.gnu.org; 23 Mar 2012 20:52:00 +0000 Received: from localhost ([127.0.0.1]:35775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBBSo-00047g-BJ for submit@debbugs.gnu.org; Fri, 23 Mar 2012 16:51:59 -0400 Received: from seluib4vp34.perspektivbredband.net ([81.186.254.26]:47054) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBBSG-00046o-I2 for 10980@debbugs.gnu.org; Fri, 23 Mar 2012 16:51:57 -0400 Received: from spc2 (hd5b913e4.seluldx.dyn.perspektivbredband.net [213.185.19.228]) by seluib4vp34.perspektivbredband.net (Postfix) with SMTP id 7C6D363ADB; Fri, 23 Mar 2012 21:20:28 +0100 (CET) Message-ID: <638D93647FE24F879BBCDB56FB6C91E0@spc2> From: "Bo Johansson" To: "Eli Zaretskii" References: <91BFD8A43A0C4F29ADF1BB30E3861DAD@spc2> <83d383uwri.fsf@gnu.org> In-Reply-To: <83d383uwri.fsf@gnu.org> Subject: Re: bug#10980: 23.4; Variable initial-environment incorrectly set Date: Fri, 23 Mar 2012 21:20:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 10980 Cc: 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.5 (-) >From: Eli Zaretskii >Date: Fri, 23 Mar 2012 18:06:57 +0200 >> From: "Bo Johansson" >> Date: Fri, 23 Mar 2012 07:30:42 +0100 >> >> On Windows the Emacs variable initial-environment is NOT set according to >> the >> documentation: >> "The variable initial-environment stores the initial environment >> inherited by >> Emacs". > >I'm sorry, I'm not sure I understand the essence of your report. What >exactly would you like the documentation to say that it doesn't say >now? Or, to put it differently, what in the way initial-environment >is set on Windows contradicts the documentation? > >Thanks. Hej Eli! My goal is: I want to get the same result doing something from within Emacs as doing it from a Windows command prompt. To do "(compile "make" nil)" within Emacs should give the same result as doing "make" from the Windows command prompt. The problem is: The environment variables inherited by Emacs is changed. The changes in the environment leads to diffren results doing something from within Emacs compared to doing it from a Windows command prompt. The BUG in Emacs is: In Windows the variable initial-environment is set first after "the initial environment inherited by Emacs" is changed. The function init_environment (char ** argv) (in emacs-git/src/w32.c at line 1528) changes the environment variables. The CHANGED "initial environment" is stored in the variable initial_environment by the function set_initial_environment (in emacs-git/src/callproc.c at line 1616). However the documentation says: "The variable initial-environment stores the initial environment inherited by Emacs". My goal can be achieved if the bug is corrected: A correct value in the variable initial-environment is need to be able to know "the environment inherited by Emacs". This make it possible to use initial-environment in the lisp function (defun compilation-start (command &optional mode name-function highlight-regexp) in emacs-git/lisp/progmodes/simple.el:2088. The in emacs internal used environment variables can temporary be override by those in the variable initial-environment. (It is of course also possible to use a new variable which contains "the initial environment inherited by Emacs".) Summary: A value in the variable initial-environment according to the documentation makes it possible to "get the same result doing something from within Emacs as doing it from a Windows command prompt". (See also http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-03/msg00178.html.) Best regards Bosse From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 23 17:36:41 2012 Received: (at 10980) by debbugs.gnu.org; 23 Mar 2012 21:36:41 +0000 Received: from localhost ([127.0.0.1]:35784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBCA4-0005Aj-QE for submit@debbugs.gnu.org; Fri, 23 Mar 2012 17:36:41 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:46275) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBC9o-0005AL-A1 for 10980@debbugs.gnu.org; Fri, 23 Mar 2012 17:36:39 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M1C00A00VVE2900@a-mtaout22.012.net.il> for 10980@debbugs.gnu.org; Fri, 23 Mar 2012 23:05:24 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.241.151]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1C0099BVWZHEH0@a-mtaout22.012.net.il>; Fri, 23 Mar 2012 23:05:24 +0200 (IST) Date: Fri, 23 Mar 2012 23:05:31 +0200 From: Eli Zaretskii Subject: Re: bug#10980: 23.4; Variable initial-environment incorrectly set In-reply-to: <638D93647FE24F879BBCDB56FB6C91E0@spc2> X-012-Sender: halo1@inter.net.il To: Bo Johansson Message-id: <8362dvuixw.fsf@gnu.org> References: <91BFD8A43A0C4F29ADF1BB30E3861DAD@spc2> <83d383uwri.fsf@gnu.org> <638D93647FE24F879BBCDB56FB6C91E0@spc2> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 10980 Cc: 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Bo Johansson" > Cc: <10980@debbugs.gnu.org> > Date: Fri, 23 Mar 2012 21:20:23 +0100 > > Summary: A value in the variable initial-environment according to the > documentation makes it possible to "get the same result doing something from > within Emacs as doing it from a Windows command prompt". > > (See also > http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-03/msg00178.html.) Is this only about SHELL, and only with dmake, or are there other variables that get in the way of other programs? Please be specific; the few changes done to the variables outside Emacs are done for a good reason, so it's important to know the exact adverse effects of that to judge how justified would it be to change the current code. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 23 19:57:25 2012 Received: (at 10980) by debbugs.gnu.org; 23 Mar 2012 23:57:25 +0000 Received: from localhost ([127.0.0.1]:35916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBEMH-0000s7-3A for submit@debbugs.gnu.org; Fri, 23 Mar 2012 19:57:25 -0400 Received: from seluib4vp34.perspektivbredband.net ([81.186.254.26]:37087) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SBEM0-0000rh-GF for 10980@debbugs.gnu.org; Fri, 23 Mar 2012 19:57:23 -0400 Received: from spc2 (hd5b913e4.seluldx.dyn.perspektivbredband.net [213.185.19.228]) by seluib4vp34.perspektivbredband.net (Postfix) with SMTP id C760363ADB; Sat, 24 Mar 2012 00:26:11 +0100 (CET) Message-ID: <6D6CE7A7BBF846CFB620FC9487A18610@spc2> From: "Bo Johansson" To: "Eli Zaretskii" References: <91BFD8A43A0C4F29ADF1BB30E3861DAD@spc2> <83d383uwri.fsf@gnu.org> <638D93647FE24F879BBCDB56FB6C91E0@spc2> <8362dvuixw.fsf@gnu.org> In-Reply-To: <8362dvuixw.fsf@gnu.org> Subject: Re: bug#10980: 23.4; Variable initial-environment incorrectly set Date: Sat, 24 Mar 2012 00:26:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 10980 Cc: 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.5 (-) >From: Eli Zaretskii >Sent: Friday, March 23, 2012 10:05 PM >> From: "Bo Johansson" >> Cc: <10980@debbugs.gnu.org> >> Date: Fri, 23 Mar 2012 21:20:23 +0100 >> >> Summary: A value in the variable initial-environment according to the >> documentation makes it possible to "get the same result doing something >> from >> within Emacs as doing it from a Windows command prompt". >> >> (See also >> http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-03/msg00178.html.) > >Is this only about SHELL, and only with dmake, or are there other >variables that get in the way of other programs? Please be specific; >the few changes done to the variables outside Emacs are done for a >good reason, so it's important to know the exact adverse effects of >that to judge how justified would it be to change the current code. It is not only about SHELL. But SHELL is the most frequent problem. Dmake and other make programs is just one among many other cases. I searched internet for "emacs" and "warning: extra args ignored after". There was +1400 hits. Many of theese depends on that SHELL is set to .../cmdproxy.exe. Adding -dmake to the search, resulted in 1280 hits. This indicates that dmake is only one case among others. In the function compilation-start (lisp/progmodes/compile.el:1166) is the variable process-environment changed. This is done TEMPORARY by using "(let ((process-environment ...". However, in many other places are "persistent" changes made by using the lisp function setenv. This is in many cases not good. Activating a function can then result in an unexpected "persistent" change of the environment. The last 20 years I have seen many unexpected things using "(compile "something" nil)", but it is first lately I have understood that one of the reasons are the changed environment. At least the functions compile and shell-command should use an as far as possible unmodified "initial environment inherited by Emacs". I am missing a strategy how to handle the environment within Emacs. I will try to find examples of other variables then SHELL! From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 28 05:28:28 2012 Received: (at 10980) by debbugs.gnu.org; 28 Mar 2012 09:28:28 +0000 Received: from localhost ([127.0.0.1]:42251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCpB5-0006jO-6I for submit@debbugs.gnu.org; Wed, 28 Mar 2012 05:28:28 -0400 Received: from seluib4vp34.perspektivbredband.net ([81.186.254.26]:40215) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SCpAo-0006j2-Fr for 10980@debbugs.gnu.org; Wed, 28 Mar 2012 05:28:25 -0400 Received: from spc2 (hd5b913e4.seluldx.dyn.perspektivbredband.net [213.185.19.228]) by seluib4vp34.perspektivbredband.net (Postfix) with SMTP id 0E51D604EC; Wed, 28 Mar 2012 10:56:48 +0200 (CEST) Message-ID: <90DA7D85167A495EBDEE340787E9CD5F@spc2> From: "Bo Johansson" To: "Eli Zaretskii" References: <91BFD8A43A0C4F29ADF1BB30E3861DAD@spc2> <83d383uwri.fsf@gnu.org> <638D93647FE24F879BBCDB56FB6C91E0@spc2> <8362dvuixw.fsf@gnu.org> In-Reply-To: <8362dvuixw.fsf@gnu.org> Subject: Re: bug#10980: 23.4; Variable initial-environment incorrectly set Date: Wed, 28 Mar 2012 10:56:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 10980 Cc: 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.5 (-) >From: Eli Zaretskii >Sent: Friday, March 23, 2012 10:05 PM >> From: "Bo Johansson" >> Cc: <10980@debbugs.gnu.org> >> Date: Fri, 23 Mar 2012 21:20:23 +0100 >> >> Summary: A value in the variable initial-environment according to the >> documentation makes it possible to "get the same result doing somethin= g=20 >> from >> within Emacs as doing it from a Windows command prompt". >> >Is this only about SHELL, and only with dmake, or are there other >variables that get in the way of other programs? Please be specific; >the few changes done to the variables outside Emacs are done for a >good reason, so it's important to know the exact adverse effects of >that to judge how justified would it be to change the current code. Hej Eli! Here is some more information. I have looked in makefile using http://code.google.com/codesearch. SHELL = and=20 COMSPEC are frequently used. In some cases is even ComSpec used. To set SHELL to c:/Program Files (x86)/GNU Emacs 23.4/bin/cmdproxy.exe=20 causes a lot of problems. The resulting errors are often difficult to find. This partly because the= =20 warning messages given by cmdproxy.exe is often given without any context= . A program developed to run in Windows, expects a =E2=80=9CWindows environ= ment=E2=80=9D!? I have compared the environment variables in different situations. The=20 differences between the environment in Windows cmd.exe and the Emacs=20 variable initial-environment are: -ComSpec=3DC:\Windows\system32\cmd.exe +COMSPEC=3DC:\Windows\system32\cmd.exe +EMACSDATA=3Dc:/Program Files (x86)/GNU Emacs 23.4/etc +EMACSDOC=3Dc:/Program Files (x86)/GNU Emacs 23.4/etc +EMACSLOADPATH=3Dc:/Program Files (x86)/GNU Emacs 23.4/site-lisp;c:/Progr= am=20 Files (x86)/GNU Emacs 23.4/../site-lisp;c:/Program Files (x86)/GNU Emacs=20 23.4/lisp;c:/Program Files (x86)/GNU Emacs 23.4/leim +EMACSPATH=3Dc:/Program Files (x86)/GNU Emacs 23.4/bin +LANG=3DSVE -Path=3D... +PATH=3D... +SHELL=3Dc:/Program Files (x86)/GNU Emacs 23.4/bin/cmdproxy.exe +TMPDIR=3DC:\Users\bo\AppData\Local\Temp +emacs_dir=3Dc:/Program Files (x86)/GNU Emacs 23.4 Comspec and Path are renamed. SHELL is added and set to the cmdproxy.exe. Differences between initial-environment to shell-command environment are: +EM_PARENT_PROCESS_ID=3D... Differences initial-environment to compile environment are: +DISPLAY=3D +EMACS=3Dt +EM_PARENT_PROCESS_ID=3D... +INSIDE_EMACS=3Dt -TERM=3Ddumb +TERM=3Demacs +TERMCAP=3Demacs:co#80:tc=3Dunknown: This comment in emacs-git/src/w32.c:1778: /* Another special case: on NT, the PATH variable is actually named "Path" although cmd.exe (perhaps NT itself) arranges for environment variable lookup and setting to be case insensitive. However, Emacs assumes a fully case sensitive environment, so we need to change "Path" to "PATH" to match the expectations of various elisp packages. We do this by the sneaky method of modifying the string in the C runtime environ entry. The same applies to COMSPEC. */ indicates that changes to the environment are mainly? made for Emacs, NOT= =20 for the processes started by Emacs. Emacs should separate the "internal=20 environment" used internally by Emacs and the external used to set up=20 external processes!? My idea to get a read-only "inherited environment" is: 1) To save the "inherited environment" early in "c-code" at start up of=20 Emacs 2) Implement a lisp function which can return the saved "inherited=20 environment". The new read-only "inherited environment" can then later be used to start= =20 external processes with a more "transparent" environment. To start to change the current handling of the variable initial-environme= nt=20 is probably difficult and error prone. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 07 23:54:34 2016 Received: (at 10980) by debbugs.gnu.org; 8 Jun 2016 03:54:34 +0000 Received: from localhost ([127.0.0.1]:59446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bAUZd-0007GR-Ul for submit@debbugs.gnu.org; Tue, 07 Jun 2016 23:54:34 -0400 Received: from mail-oi0-f46.google.com ([209.85.218.46]:33619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bAUZT-0007Ft-9b for 10980@debbugs.gnu.org; Tue, 07 Jun 2016 23:54:32 -0400 Received: by mail-oi0-f46.google.com with SMTP id k23so309100606oih.0 for <10980@debbugs.gnu.org>; Tue, 07 Jun 2016 20:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R5TKlFgE465G4SLxBWamN+wVglsiltHQmrQSQbcG60E=; b=ilBp+/wtN+nRSpp3yf/JCryWSWDLjwStOCUL0v41r/sjYfxAjulYeDOfc1r+VP5r/Y yft6ma2RITirgDOd4NDu5mqQ0kJAzk5Qn8KlgAoxXx0Xh1e3GY4lV40rnXep7kAyDRFd WdPN2w/nlMq4VtUUw63z63Z+wz656LU/3I6gAkfIZXXBgcn+3co7OGi2R2Ub1JksDGIE 3gDe+lChbxJ0HZlqh5wa9Jqq3L218+09bfzfAjKENFYvIH+Vcy49ir/l+1Tov3BU84yx DmSIefqhascNARgMFXz9eDnNJ4ME+f1dOR2a9j+rVAVCZQ9fGBVSzx0tRCArRj2cV5NP JVvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=R5TKlFgE465G4SLxBWamN+wVglsiltHQmrQSQbcG60E=; b=TU+M8QsQyMpggrDlw2zUT4V34BOlOtoB4Jp2c1JV98Qsi9419wuUCuY6ITBizUMzM5 CAl4Bz5VO6ICINFlk/Rt+Q+z28K3zIwxRyCRhCgfw7z3wgs2eP0YDWlXJznbT+ba7Zp6 oiE+Ozu6PSela4HiJC5SHx1HNQ7P/04xv46IJmgMfZZbRVd0CPKdWtNkdiai5pzWB9eD GGpH+y/9xsAbGjSRNGLMj8GnfIs5vbWroiswLhQoF5eF0Qq+EnraIWmBD7PNdP2hppoX GEVx9MMKBFbaCb0R8O7Y77kIlZxpzWM6RqXFh/Z32/H1tEP6gmhKB4xcHqDUAtaYZLwu mEkQ== X-Gm-Message-State: ALyK8tJ8UMGZCSaSgZtSFreI7jI2R4a4OieFwTX8YWNa2+bBRw7pIdtZn8kBxbv4gao7agGizgV3JrhSjBg3yQ== X-Received: by 10.202.75.80 with SMTP id y77mr1697165oia.144.1465358057651; Tue, 07 Jun 2016 20:54:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.5.168 with HTTP; Tue, 7 Jun 2016 20:54:17 -0700 (PDT) In-Reply-To: References: From: Noam Postavsky Date: Tue, 7 Jun 2016 23:54:17 -0400 X-Google-Sender-Auth: qDPww6BgfD2P5sVKI0u295OKRS8 Message-ID: Subject: Re: GNU bugs information: logs for bug#10980 To: 10980@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) severity 10980 wishlist quit > From: "Bo Johansson" lsn.se> > To: "Eli Zaretskii" gnu.org> > Cc: 10980 debbugs.gnu.org > Subject: Re: bug#10980: 23.4; Variable initial-environment incorrectly set > Date: Wed, 28 Mar 2012 10:56:44 +0200 > > My idea to get a read-only "inherited environment" is: > 1) To save the "inherited environment" early in "c-code" at start up of > Emacs > 2) Implement a lisp function which can return the saved "inherited > environment". > > The new read-only "inherited environment" can then later be used to start > external processes with a more "transparent" environment. > To start to change the current handling of the variable initial-environment > is probably difficult and error prone. > I read this as a feature request to let lisp programs be able to see the environment from before Emacs startup routines have changed it. I have an additional use case for this: in magit it would be useful to see if the user has HOME or if they just let Emacs choose a default value for it. In the latter case, I would pop up a warning to tell them not to do that because git chooses a different default value HOME, and having disagreement causes confusion (of the "why does X work from command line and not in magit?" variety). From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 08 12:40:18 2016 Received: (at 10980) by debbugs.gnu.org; 8 Jun 2016 16:40:18 +0000 Received: from localhost ([127.0.0.1]:33032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bAgWf-0007B9-Tb for submit@debbugs.gnu.org; Wed, 08 Jun 2016 12:40:18 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47128) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bAgWe-0007Ax-Bs for 10980@debbugs.gnu.org; Wed, 08 Jun 2016 12:40:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAgWU-00070P-8F for 10980@debbugs.gnu.org; Wed, 08 Jun 2016 12:40:11 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAgWA-0006rj-Tv; Wed, 08 Jun 2016 12:39:46 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1374 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bAgWA-0007tp-27; Wed, 08 Jun 2016 12:39:46 -0400 Date: Wed, 08 Jun 2016 19:40:24 +0300 Message-Id: <83twh3r5vr.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Tue, 7 Jun 2016 23:54:17 -0400) Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > From: Noam Postavsky > Date: Tue, 7 Jun 2016 23:54:17 -0400 > Cc: bo.johansson@lsn.se > > > My idea to get a read-only "inherited environment" is: > > 1) To save the "inherited environment" early in "c-code" at start up of > > Emacs > > 2) Implement a lisp function which can return the saved "inherited > > environment". > > > > The new read-only "inherited environment" can then later be used to start > > external processes with a more "transparent" environment. > > To start to change the current handling of the variable initial-environment > > is probably difficult and error prone. > > > > I read this as a feature request to let lisp programs be able to see > the environment from before Emacs startup routines have changed it. I don't think we want to have environment-related functions that are specific to Windows, that goes against the goal of portability of Emacs packages. I'm okay with considering patches specific to w32 that would eliminate the need for pushing variables into the environment of subprocesses, and/or leave initial-environment unaffected by the pushed values, but no one has stepped forward for the job. > I have an additional use case for this: in magit it would be useful > to see if the user has HOME or if they just let Emacs choose a > default value for it. In the latter case, I would pop up a warning > to tell them not to do that because git chooses a different default > value HOME, and having disagreement causes confusion (of the "why > does X work from command line and not in magit?" variety). I guess you refer to the fact that msysgit uses $USERPROFILE as the alternative home directory if $HOME is not set? If so, I'd rather suggest to report a bug to msysgit maintainers: they are behaving against platform recommendations. From https://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx: CSIDL_PROFILE FOLDERID_Profile The user's profile folder. A typical path is C:\Users\username. Applications should not create files or folders at this level; they should put their data under the locations referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. However, if you are creating a new Known Folder the profile root referred to by CSIDL_PROFILE is appropriate. If you look in the $USERPROFILE directory on a typical Windows machine, you won't see there any sub-directory or file created by an application, only a few standard sub-directories. Applications do generally follow the above recommendations; for example, I have Firefox installed, which keeps my customizations in $APPDATA/Mozilla/Firefox/Profiles/. So Git is the odd one out if it puts its ~/.gitconfig file in $USERPROFILE. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 20 20:23:37 2016 Received: (at 10980) by debbugs.gnu.org; 21 Jun 2016 00:23:37 +0000 Received: from localhost ([127.0.0.1]:48180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF9Td-0007tu-6n for submit@debbugs.gnu.org; Mon, 20 Jun 2016 20:23:37 -0400 Received: from mail-ob0-f178.google.com ([209.85.214.178]:34036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bF9TY-0007tg-Vo for 10980@debbugs.gnu.org; Mon, 20 Jun 2016 20:23:35 -0400 Received: by mail-ob0-f178.google.com with SMTP id ru5so798014obc.1 for <10980@debbugs.gnu.org>; Mon, 20 Jun 2016 17:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UOzVtDWSq8suHh8SBhtGgCPTnu62Ecs+CUiAFiLV5xY=; b=b6EuS31VYHIHmmisgeG0XtpxQ7LGLyfCDf4YjgoWa9tPLK/6x4r/USW5ZVlV7e4Gz7 4YUdZ9ibvqOqtOZERLhh7dIjYRAD8ZRWfZG+60WO29z58okhGcWHlqnTHGpta2AhVwsj IqbDl5Ik9DXymUIxHT9U0ZdiFYs8mQSYRM+bwR4DYtS1CmsYdKYwP5fKtm5XOL7B3Wer n+FlvQsY00XDz5ryyBw2LGySieN/geaL3W9F0rQF026VjLbCBsggitvh5F2jr8uX/+x9 cGbGhKxpCyEieqcmR1GX3QEkD7p7s6cFnaBI1PppbGwJUrTPuQrtqppd4RTXG2/kiUEW NFJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UOzVtDWSq8suHh8SBhtGgCPTnu62Ecs+CUiAFiLV5xY=; b=dJN6xfN+ypR0dGbn/H0CFn9wjjxaGxDTG0XdMrlYeW9I9TSRZnZ7FK8VKRutUG1dRa WLxk1g1bVz0ADWnNLrWeq6XISS0u+/AkcUbdpYLC2KALhjdrWvdukyqxwQFwTHmlBMxB In042HFGdY2/DZOZoqXw+coyfMf2DQshDUAaleynS0B+ZGDddMUh5uMVMpgCbGfPrEsa RcVvSAiyHJytQLlKmWzwPQH58UXpw/qYgIXHU893QiKWLa/OANN2eRhP5o1p5CduWOZo baAEgqp6feszO9yVa55bn72WMvwS9K5z8CxJ7BBmCRygvtNH/5LvPMqTPLj2WPEbnVYk 2Bug== X-Gm-Message-State: ALyK8tLezijY+Qsvzaeoh2fI9VhqY6z47EoJO12y4uRu1GR+/l3nlbSsqFPT5Msrs2HiYFVdxyMbLPGCacuarw== X-Received: by 10.157.38.185 with SMTP id l54mr13069217otb.112.1466468607306; Mon, 20 Jun 2016 17:23:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.238 with HTTP; Mon, 20 Jun 2016 17:23:26 -0700 (PDT) In-Reply-To: <83twh3r5vr.fsf@gnu.org> References: <83twh3r5vr.fsf@gnu.org> From: Noam Postavsky Date: Mon, 20 Jun 2016 20:23:26 -0400 X-Google-Sender-Auth: CNusS2sMxUx2SEvRGPETlkjn8iQ Message-ID: Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 To: Eli Zaretskii Content-Type: multipart/mixed; boundary=001a1139478469ca5d0535bed48c X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --001a1139478469ca5d0535bed48c Content-Type: text/plain; charset=UTF-8 On Wed, Jun 8, 2016 at 12:40 PM, Eli Zaretskii wrote: > I don't think we want to have environment-related functions that are > specific to Windows, that goes against the goal of portability of > Emacs packages. > > I'm okay with considering patches specific to w32 that would eliminate > the need for pushing variables into the environment of subprocesses, > and/or leave initial-environment unaffected by the pushed values How about splitting apart initialization of Vinitial_environment and Vprocess_environment and moving the former earlier so that it's unaffected by Emacs' manipulations of the environment? See attached patch. > I guess you refer to the fact that msysgit uses $USERPROFILE as the > alternative home directory if $HOME is not set? If so, I'd rather > suggest to report a bug to msysgit maintainers: they are behaving > against platform recommendations. [...] > If you look in the $USERPROFILE directory on a typical Windows > machine, you won't see there any sub-directory or file created by an > application, only a few standard sub-directories. Applications do > generally follow the above recommendations; for example, I have > Firefox installed, which keeps my customizations in > $APPDATA/Mozilla/Firefox/Profiles/. So Git is the odd one out if it > puts its ~/.gitconfig file in $USERPROFILE. To me it makes sense to have $HOME map to $USERPROFILE, and $APPDATA is like $XDG_CONFIG_HOME (usually ~/.config/ on GNU/Linux). However, this is purely subjective as there are no platform recommendations about translating environment variables to other platforms. --001a1139478469ca5d0535bed48c Content-Type: application/octet-stream; name="0001-Set-Vinitial_environment-before-changing-env-vars.patch" Content-Disposition: attachment; filename="0001-Set-Vinitial_environment-before-changing-env-vars.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ipoph6250 RnJvbSBkNjdmYjE1ZmRjZDdhNzQyY2UwYmI3OTYzZGRjZmVhNDMwZjdlZjE5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOb2FtIFBvc3RhdnNreSA8bnBvc3RhdnNAZ21haWwuY29tPgpE YXRlOiBNb24sIDIwIEp1biAyMDE2IDIwOjA4OjE1IC0wNDAwClN1YmplY3Q6IFtQQVRDSF0gU2V0 IFZpbml0aWFsX2Vudmlyb25tZW50IGJlZm9yZSBjaGFuZ2luZyBlbnYgdmFycwoKKiBzcmMvY2Fs bHByb2MuYyAobWFrZV9saXN0X2Zyb21fZW52aXJvbik6IFJlbmFtZWQgZnJvbQpzZXRfaW5pdGlh bF9lbnZpcm9ubWVudCwganVzdCByZXR1cm4gYSBMaXNwIGxpc3Qgb2YgdGhlIGVudmlyb25tZW50 Cmluc3RlYWQgb2Ygc2V0dGluZyBvZiBWcHJvY2Vzc19lbnZpcm9ubWVudCBhbmQgVmluaXRpYWxf ZW52aXJvbm1lbnQKZGlyZWN0bHkuCiogc3JjL2VtYWNzLmMgKG1haW4pOiBTZXQgVmluaXRpYWxf ZW52aXJvbm1lbnQgYmVmb3JlIGluaXRfZW52aXJvbm1lbnQKaXMgY2FsbGVkIHNvIHRoYXQgaXQg Z2V0cyB0aGUgaW5pdGlhbCBlbnZpcm9ubWVudCBpbmhlcml0ZWQgZnJvbSB0aGUKcGFyZW50IHBy b2Nlc3MgYW5kIHJlbWFpbnMgdW5hZmZlY3RlZCBieSBtb2RpZmljYXRpb25zIEVtYWNzCnBlcmZv cm1zIChCdWcgIzEwOTgwKS4KLS0tCiBzcmMvY2FsbHByb2MuYyB8IDEyICsrKysrLS0tLS0tLQog c3JjL2VtYWNzLmMgICAgfCAxNCArKysrKysrKy0tLS0tLQogc3JjL2xpc3AuaCAgICAgfCAgMiAr LQogMyBmaWxlcyBjaGFuZ2VkLCAxNCBpbnNlcnRpb25zKCspLCAxNCBkZWxldGlvbnMoLSkKCmRp ZmYgLS1naXQgYS9zcmMvY2FsbHByb2MuYyBiL3NyYy9jYWxscHJvYy5jCmluZGV4IDA3Mjk3ODIu LjkyNGI3NTUgMTAwNjQ0Ci0tLSBhL3NyYy9jYWxscHJvYy5jCisrKyBiL3NyYy9jYWxscHJvYy5j CkBAIC0xNTc3LDE2ICsxNTc3LDE0IEBAIGluaXRfY2FsbHByb2MgKHZvaWQpCiAjZW5kaWYKIH0K IAotdm9pZAotc2V0X2luaXRpYWxfZW52aXJvbm1lbnQgKHZvaWQpCitMaXNwX09iamVjdAorbWFr ZV9saXN0X2Zyb21fZW52aXJvbiAodm9pZCkKIHsKICAgY2hhciAqKmVudnA7CisgIExpc3BfT2Jq ZWN0IGxpc3QgPSBRbmlsOwogICBmb3IgKGVudnAgPSBlbnZpcm9uOyAqZW52cDsgZW52cCsrKQot ICAgIFZwcm9jZXNzX2Vudmlyb25tZW50ID0gRmNvbnMgKGJ1aWxkX3N0cmluZyAoKmVudnApLAot CQkJCSAgVnByb2Nlc3NfZW52aXJvbm1lbnQpOwotICAvKiBJZGVhbGx5LCB0aGUgYGNvcHknIHNo b3VsZG4ndCBiZSBuZWNlc3NhcnksIGJ1dCBpdCBzZWVtcyBpdCdzIGZyZXF1ZW50Ci0gICAgIHRv IHVzZSBgZGVsZXRlJyBhbmQgZnJpZW5kcyBvbiBwcm9jZXNzLWVudmlyb25tZW50LiAgKi8KLSAg VmluaXRpYWxfZW52aXJvbm1lbnQgPSBGY29weV9zZXF1ZW5jZSAoVnByb2Nlc3NfZW52aXJvbm1l bnQpOworICAgIGxpc3QgPSBGY29ucyAoYnVpbGRfc3RyaW5nICgqZW52cCksIGxpc3QpOworICBy ZXR1cm4gbGlzdDsKIH0KIAogdm9pZApkaWZmIC0tZ2l0IGEvc3JjL2VtYWNzLmMgYi9zcmMvZW1h Y3MuYwppbmRleCBiYjg1NzMzLi4xZGJiM2Y2IDEwMDY0NAotLS0gYS9zcmMvZW1hY3MuYworKysg Yi9zcmMvZW1hY3MuYwpAQCAtMTIxMCwxMCArMTIxMCwxNyBAQCBVc2luZyBhbiBFbWFjcyBjb25m aWd1cmVkIHdpdGggLS13aXRoLXgtdG9vbGtpdD1sdWNpZCBkb2VzIG5vdCBoYXZlIHRoaXMgcHJv YmxlbQogI2lmZGVmIEhBVkVfV0lORE9XX1NZU1RFTQogICAgICAgaW5pdF9mcmluZ2Vfb25jZSAo KTsJLyogU3dhcCBiaXRtYXBzIGlmIG5lY2Vzc2FyeS4gICovCiAjZW5kaWYgLyogSEFWRV9XSU5E T1dfU1lTVEVNICovCisKKyAgICAgIC8qIEluaXRpYWxpemUgYW5kIEdDLXByb3RlY3QgVmluaXRp YWxfZW52aXJvbm1lbnQgYW5kIFZwcm9jZXNzX2Vudmlyb25tZW50CisgICAgICAgICBiZWZvcmUg ZmlsbGluZyB0aGVtIGluLiAgKi8KKyAgICAgIHN5bXNfb2ZfY2FsbHByb2MgKCk7CiAgICAgfQog CiAgIGluaXRfYWxsb2MgKCk7CiAKKyAgaWYgKCEgZHVtcGluZykKKyAgICBWaW5pdGlhbF9lbnZp cm9ubWVudCA9IG1ha2VfbGlzdF9mcm9tX2Vudmlyb24gKCk7CisKICAgaWYgKGRvX2luaXRpYWxf c2V0bG9jYWxlKQogICAgIHsKICAgICAgIGZpeHVwX2xvY2FsZSAoKTsKQEAgLTEzNjYsMTYgKzEz NzMsMTEgQEAgVXNpbmcgYW4gRW1hY3MgY29uZmlndXJlZCB3aXRoIC0td2l0aC14LXRvb2xraXQ9 bHVjaWQgZG9lcyBub3QgaGF2ZSB0aGlzIHByb2JsZW0KICAgbnNfaW5pdF9sb2NhbGUgKCk7CiAj ZW5kaWYKIAotICAvKiBJbml0aWFsaXplIGFuZCBHQy1wcm90ZWN0IFZpbml0aWFsX2Vudmlyb25t ZW50IGFuZAotICAgICBWcHJvY2Vzc19lbnZpcm9ubWVudCBiZWZvcmUgc2V0X2luaXRpYWxfZW52 aXJvbm1lbnQgZmlsbHMgdGhlbQotICAgICBpbi4gICovCi0gIGlmICghaW5pdGlhbGl6ZWQpCi0g ICAgc3ltc19vZl9jYWxscHJvYyAoKTsKICAgLyogZWdldGVudiBpcyBhIHByZXR0eSBsb3ctbGV2 ZWwgZmFjaWxpdHksIHdoaWNoIG1heSBnZXQgY2FsbGVkIGluCiAgICAgIG1hbnkgY2lyY3Vtc3Rh bmNlczsgaXQgc2VlbXMgZmxpbXN5IHRvIHB1dCBvZmYgaW5pdGlhbGl6aW5nIGl0CiAgICAgIHVu dGlsIGNhbGxpbmcgaW5pdF9jYWxscHJvYy4gIERvIG5vdCBkbyBpdCB3aGVuIGR1bXBpbmcuICAq LwogICBpZiAoISBkdW1waW5nKQotICAgIHNldF9pbml0aWFsX2Vudmlyb25tZW50ICgpOworICAg IFZwcm9jZXNzX2Vudmlyb25tZW50ID0gbWFrZV9saXN0X2Zyb21fZW52aXJvbiAoKTsKIAogICAv KiBBSVggY3Jhc2hlcyBhcmUgcmVwb3J0ZWQgaW4gc3lzdGVtIHZlcnNpb25zIDMuMi4zIGFuZCAz LjIuNAogICAgICBpZiB0aGlzIGlzIG5vdCBkb25lLiAgRG8gaXQgYWZ0ZXIgc2V0X2dsb2JhbF9l bnZpcm9ubWVudCBzbyB0aGF0IHdlCmRpZmYgLS1naXQgYS9zcmMvbGlzcC5oIGIvc3JjL2xpc3Au aAppbmRleCBlMGViNTJhLi4zM2UxZjcwIDEwMDY0NAotLS0gYS9zcmMvbGlzcC5oCisrKyBiL3Ny Yy9saXNwLmgKQEAgLTQxOTksNyArNDE5OSw3IEBAIGV4dGVybiB2b2lkIHNldHVwX3Byb2Nlc3Nf Y29kaW5nX3N5c3RlbXMgKExpc3BfT2JqZWN0KTsKIGV4dGVybiBpbnQgY2hpbGRfc2V0dXAgKGlu dCwgaW50LCBpbnQsIGNoYXIgKiosIGJvb2wsIExpc3BfT2JqZWN0KTsKIGV4dGVybiB2b2lkIGlu aXRfY2FsbHByb2NfMSAodm9pZCk7CiBleHRlcm4gdm9pZCBpbml0X2NhbGxwcm9jICh2b2lkKTsK LWV4dGVybiB2b2lkIHNldF9pbml0aWFsX2Vudmlyb25tZW50ICh2b2lkKTsKK2V4dGVybiBMaXNw X09iamVjdCBtYWtlX2xpc3RfZnJvbV9lbnZpcm9uICh2b2lkKTsKIGV4dGVybiB2b2lkIHN5bXNf b2ZfY2FsbHByb2MgKHZvaWQpOwogCiAvKiBEZWZpbmVkIGluIGRvYy5jLiAgKi8KLS0gCjIuNi4y LndpbmRvd3MuMQoK --001a1139478469ca5d0535bed48c-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 09:29:03 2016 Received: (at 10980) by debbugs.gnu.org; 21 Jun 2016 13:29:03 +0000 Received: from localhost ([127.0.0.1]:48810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFLji-0003bA-OP for submit@debbugs.gnu.org; Tue, 21 Jun 2016 09:29:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55138) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFLjh-0003ae-HV for 10980@debbugs.gnu.org; Tue, 21 Jun 2016 09:29:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFLjb-0004ne-DC for 10980@debbugs.gnu.org; Tue, 21 Jun 2016 09:28:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44246) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFLjS-0004j4-GZ; Tue, 21 Jun 2016 09:28:46 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4785 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bFLjR-00063f-ET; Tue, 21 Jun 2016 09:28:45 -0400 Date: Tue, 21 Jun 2016 16:27:54 +0300 Message-Id: <83d1na7jtx.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Mon, 20 Jun 2016 20:23:26 -0400) Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 References: <83twh3r5vr.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.4 (------) > From: Noam Postavsky > Date: Mon, 20 Jun 2016 20:23:26 -0400 > Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se > > > I'm okay with considering patches specific to w32 that would eliminate > > the need for pushing variables into the environment of subprocesses, > > and/or leave initial-environment unaffected by the pushed values > > How about splitting apart initialization of Vinitial_environment and > Vprocess_environment and moving the former earlier so that it's > unaffected by Emacs' manipulations of the environment? See attached > patch. Thanks. However, I wonder if we could do better. First, your patch only fixed initial-environment, which means Lisp applications will need to explicitly use it, and probably only on Windows, something that is not the best solution, IMO. I hoped we could come up with a way of pushing the additional variables into Emacs's own environment after Vprocess_environment is already computed -- can you try doing that? In any case, the reasons for calling the same function twice in two different places should be explained, at least in the comments, or else someone might become confused at some future point in time. Better yet, perhaps only the Windows build should do something like that, and the other platforms could continue using the current code mostly unaltered, as they don't need this. > > If you look in the $USERPROFILE directory on a typical Windows > > machine, you won't see there any sub-directory or file created by an > > application, only a few standard sub-directories. Applications do > > generally follow the above recommendations; for example, I have > > Firefox installed, which keeps my customizations in > > $APPDATA/Mozilla/Firefox/Profiles/. So Git is the odd one out if it > > puts its ~/.gitconfig file in $USERPROFILE. > > To me it makes sense to have $HOME map to $USERPROFILE, and $APPDATA > is like $XDG_CONFIG_HOME (usually ~/.config/ on GNU/Linux). However, > this is purely subjective as there are no platform recommendations > about translating environment variables to other platforms. I quoted the platform recommendations that discourage putting files directly under $USERPROFILE, and most programs, including those ported from Posix platforms, do seem to follow those recommendations. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 17:03:29 2016 Received: (at 10980) by debbugs.gnu.org; 21 Jun 2016 21:03:29 +0000 Received: from localhost ([127.0.0.1]:50094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFSpV-0006Qh-Jr for submit@debbugs.gnu.org; Tue, 21 Jun 2016 17:03:29 -0400 Received: from mail-oi0-f53.google.com ([209.85.218.53]:35030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFSpT-0006QR-Nz for 10980@debbugs.gnu.org; Tue, 21 Jun 2016 17:03:28 -0400 Received: by mail-oi0-f53.google.com with SMTP id r2so3751138oih.2 for <10980@debbugs.gnu.org>; Tue, 21 Jun 2016 14:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9Nzz0/HbeiV/b95qf9goF169oLWXbOQI3QJB/zh9byo=; b=BTA4Y2NHIvbMG8F0qBF+/quQu30lUWsj19CfCb2wYcphjul44TbOExEKDu9Vz7biw7 4XvAaUGCGvCfxwsmKfSh0vHBpEsmm5EPGMbG0sGtk9463w974EnMTqNfTe4jWodTH2Fm 0tLM6NusVwsjhbluGQPuZM3EYCGf9QKIRZHXYYwEUuQhyE90bIn+3wgdU/ECXZLYQgVj hnLWfNWsCDBGnsbkvNmyNRXy+B5FSLk4Iub2RHHbtR5o36kltTbKgepRhVPi8t5wXj04 EZg4kvRCSot90npkdTKZ8I6cXO54iiTPpa4HClrZLSMS373EtNafZEZA7hnkWkZ3kNWX kkhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9Nzz0/HbeiV/b95qf9goF169oLWXbOQI3QJB/zh9byo=; b=HbCZ+lySa3BlO5ubu1rwS2EBswcmT1VinJ+egbn/vsTAzd1UkNLl/uM26LLf3+VZly vzV2jaTPmRTCycfSlQrtN1KApmf+W8A8FF/kUbZgVpcU5Ho2gT8bzUAsfIlEy+rvVgbL 3ayEkwUuMajbRYFGC11iZqvwNSbeYRFuCNLymAVl40pAX2iXTyos4TrWAbjSYyir4MjP P5G1vwVRsLgRJBTKvP8sLrhGsBwKwSeoGmia9kE7bmlFZqkGZ91jwVMtzo4pFqwOkj+n bpXL0MM0IbYRjWwvLWnPN71DxX8m46cIUGZoxmMT1FMeKsC/pFOAT4XH7w49j/JgFGan Ms3A== X-Gm-Message-State: ALyK8tJa4TuKS8dHmis8pMPC1ZoLsN9NXp2pgQiqVIQvJMk4YxTlBEmgUklfbuXCOgiLBKVU/SSDBWbKVfIg0Q== X-Received: by 10.157.49.119 with SMTP id v52mr17974654otd.134.1466543001957; Tue, 21 Jun 2016 14:03:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.238 with HTTP; Tue, 21 Jun 2016 14:03:21 -0700 (PDT) In-Reply-To: <83d1na7jtx.fsf@gnu.org> References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> From: Noam Postavsky Date: Tue, 21 Jun 2016 17:03:21 -0400 X-Google-Sender-Auth: DNwA0BRfNdmWOt_kkAxNXZQd8Nw Message-ID: Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Jun 21, 2016 at 9:27 AM, Eli Zaretskii wrote: >> How about splitting apart initialization of Vinitial_environment and >> Vprocess_environment and moving the former earlier so that it's >> unaffected by Emacs' manipulations of the environment? See attached >> patch. > > Thanks. However, I wonder if we could do better. First, your patch > only fixed initial-environment, which means Lisp applications will > need to explicitly use it, and probably only on Windows, Well, Lisp applications that want the environment as Emacs originally received it will use initial-environment regardless of platform (without the patch, on Windows, they get an environment with some modifications from Emacs). > that is not the best solution, IMO. I hoped we could come up with a > way of pushing the additional variables into Emacs's own environment > after Vprocess_environment is already computed -- can you try doing > that? I feel like I'm missing some important point here. If these environment variables won't affect subprocess environments, why set them at all? > > In any case, the reasons for calling the same function twice in two > different places should be explained, at least in the comments, or > else someone might become confused at some future point in time. Right. > Better yet, perhaps only the Windows build should do something like > that, and the other platforms could continue using the current code > mostly unaltered, as they don't need this. Isn't it simpler to do the same thing on all platforms? They don't need a different approach, but it doesn't hurt either. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 22:40:26 2016 Received: (at 10980) by debbugs.gnu.org; 22 Jun 2016 02:40:26 +0000 Received: from localhost ([127.0.0.1]:50217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFY5a-0007Uw-BN for submit@debbugs.gnu.org; Tue, 21 Jun 2016 22:40:26 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54114) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFY5Y-0007Uj-Df for 10980@debbugs.gnu.org; Tue, 21 Jun 2016 22:40:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFY5Q-00047w-60 for 10980@debbugs.gnu.org; Tue, 21 Jun 2016 22:40:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFY5F-0003ud-2u; Tue, 21 Jun 2016 22:40:05 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1365 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bFY5E-00072C-2R; Tue, 21 Jun 2016 22:40:04 -0400 Date: Wed, 22 Jun 2016 05:39:14 +0300 Message-Id: <83k2hi54ml.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Tue, 21 Jun 2016 17:03:21 -0400) Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.5 (------) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.5 (------) > From: Noam Postavsky > Date: Tue, 21 Jun 2016 17:03:21 -0400 > Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se > > I feel like I'm missing some important point here. If these > environment variables won't affect subprocess environments, why set > them at all? Because Emacs itself needs them. They must be in Emacs's environment, but don't have to be in Vprocess_environment. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 21 22:54:32 2016 Received: (at 10980) by debbugs.gnu.org; 22 Jun 2016 02:54:32 +0000 Received: from localhost ([127.0.0.1]:50226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFYJE-0007oF-1D for submit@debbugs.gnu.org; Tue, 21 Jun 2016 22:54:32 -0400 Received: from mail-oi0-f46.google.com ([209.85.218.46]:35042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFYJD-0007o3-E4 for 10980@debbugs.gnu.org; Tue, 21 Jun 2016 22:54:31 -0400 Received: by mail-oi0-f46.google.com with SMTP id r2so3128126oih.2 for <10980@debbugs.gnu.org>; Tue, 21 Jun 2016 19:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ED9Oa8MruwzWFkg7igX4ZC3K7ccYlXopyK8lCDfDqhE=; b=QoOrt3ZIdAo9F9r0xfydpwCNCx5V72EojC5Sy5c0TihlWHRg3K+f9vmUiQXXutO+4H j+uGJUo/Fit5Zvgubv6g6yDaKsYpioIAQI+SJKkiLIG8U5QF7y+wndA7XJCJOn0aUDIu fcSfd5ZlnA7Ea6CzrANEL67/pQrGdRveSH+l3apx5voOEVeqFL89dnlvJfkyyDRY4Qqf iYk2YMQougsvoCUwlcmGM1rKk6Wuzn4qES6JKrzGmGRAqsZO+tJfuLS4J7wME4MOvSJH OusHF6SPkxElRinb1qdCTEc4QLF1jm2oVnsytU+C1MYI9rQJS8pdYm6cOLHU3PYYrHv3 dYLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ED9Oa8MruwzWFkg7igX4ZC3K7ccYlXopyK8lCDfDqhE=; b=D8QWCD/3B3hEgS+rpM5kkDXnlxJubROuT4o2LoMt+B20u4vJ/wr5EYxoy3iaLOsl7p JkkS9re9kITDweMgBPqIkywcR/F5lVDdYWgdCxxDis6QRhQbD9LklcHDv0X3c8+9OdsJ RDqqCr8t9XOQKub9w8PnizoU1xFPLKwGIwvhvLVSMN8RvEaH+iLTVxOtSxzXGBwhJrW7 07W6Tde2fm9N9k3WsUj5ux2sfRclzCaz/2n7UkUyNPpZ774VmIeGoThm9oua31KsJ3cz 03h8EabYN3CbqehZRj/wyhwE3PWsJQpVYLzJzn2hjm/JmMmcOEjptVdUVCy47dreTl3z t5Hg== X-Gm-Message-State: ALyK8tKUB6LBGdugWAbTy9rr1Q+5uacNAW5nvRucFIUHa/QxZ8SbqwnksJkDuJOOO2yIw+42071yNiQJi5I0zQ== X-Received: by 10.202.207.16 with SMTP id f16mr207126oig.178.1466564065629; Tue, 21 Jun 2016 19:54:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.238 with HTTP; Tue, 21 Jun 2016 19:54:25 -0700 (PDT) In-Reply-To: <83k2hi54ml.fsf@gnu.org> References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> <83k2hi54ml.fsf@gnu.org> From: Noam Postavsky Date: Tue, 21 Jun 2016 22:54:25 -0400 X-Google-Sender-Auth: veFsXayqQyQqs9JxR3bIn4lBWog Message-ID: Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Jun 21, 2016 at 10:39 PM, Eli Zaretskii wrote: >> From: Noam Postavsky >> Date: Tue, 21 Jun 2016 17:03:21 -0400 >> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se >> >> I feel like I'm missing some important point here. If these >> environment variables won't affect subprocess environments, why set >> them at all? > > Because Emacs itself needs them. They must be in Emacs's environment, > but don't have to be in Vprocess_environment. What does it need them for? Just because Emacs consults the values from its environment? Is there some reason not to use just plain old global variables? From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 22 10:59:31 2016 Received: (at 10980) by debbugs.gnu.org; 22 Jun 2016 14:59:31 +0000 Received: from localhost ([127.0.0.1]:51288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFjcp-0004pC-4B for submit@debbugs.gnu.org; Wed, 22 Jun 2016 10:59:31 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFjck-0004ox-Up for 10980@debbugs.gnu.org; Wed, 22 Jun 2016 10:59:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFjcW-0004Pr-Kg for 10980@debbugs.gnu.org; Wed, 22 Jun 2016 10:59:21 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFjc7-0004Nt-OW; Wed, 22 Jun 2016 10:58:47 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1852 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bFjc1-0006qH-Ef; Wed, 22 Jun 2016 10:58:44 -0400 Date: Wed, 22 Jun 2016 17:57:30 +0300 Message-Id: <83fus55l0l.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Tue, 21 Jun 2016 22:54:25 -0400) Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> <83k2hi54ml.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.5 (------) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.5 (------) > From: Noam Postavsky > Date: Tue, 21 Jun 2016 22:54:25 -0400 > Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se > > On Tue, Jun 21, 2016 at 10:39 PM, Eli Zaretskii wrote: > >> From: Noam Postavsky > >> Date: Tue, 21 Jun 2016 17:03:21 -0400 > >> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se > >> > >> I feel like I'm missing some important point here. If these > >> environment variables won't affect subprocess environments, why set > >> them at all? > > > > Because Emacs itself needs them. They must be in Emacs's environment, > > but don't have to be in Vprocess_environment. > > What does it need them for? Various features in Emacs rely on them to be present and valid (because that's what happens on Posix systems). > Just because Emacs consults the values from its environment? Yes. > Is there some reason not to use just plain old global variables? On all platforms, or just on Windows? In any case, doing that would mean a much larger job, even if it's possible. E.g., how do you deal with Lisp code that expects (expand-file-name "~") and (getenv "HOME") to yield the same value? From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 29 09:12:47 2016 Received: (at 10980) by debbugs.gnu.org; 29 Jun 2016 13:12:47 +0000 Received: from localhost ([127.0.0.1]:59741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIFIN-0002qK-Hl for submit@debbugs.gnu.org; Wed, 29 Jun 2016 09:12:47 -0400 Received: from mail-ob0-f177.google.com ([209.85.214.177]:36532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIFIM-0002q6-BU for 10980@debbugs.gnu.org; Wed, 29 Jun 2016 09:12:46 -0400 Received: by mail-ob0-f177.google.com with SMTP id mu6so24622483obc.3 for <10980@debbugs.gnu.org>; Wed, 29 Jun 2016 06:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GMwNbaIx9ZDxSnuds/4/RKpPYFREPNYg7LTX/BTt1Dk=; b=A6jN9zP3lh9/HnNMF5UbzNOhv7j2OAgpo/CxYBednSel8bqEO1TZs18iDaGx08jgtx JMfkxPzDE/lf0bM72dKxuR0MfaYH7AkbicE8Pgvnp3allWsZ+18J+wzZonErEEbnGj8a 7jewcnQtucsjQF3oZN7tWOmXgdHmm7pGdJ7QQNxS90nOwwJ9/BMwXvusgUjo2m7Do5Uv OktMz0Z9ApsKtwhRAtBFWdaWoADBhGNWyk3FkhsiRFzsL98dhhAFElUCFg6Q1pLivwoS eu5hboKv3DfOVFvn1umk1/1g0mUKaXnfEeVcnchAO2XPPggsnzwfSywvcYPPI4rXQGIh f+LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GMwNbaIx9ZDxSnuds/4/RKpPYFREPNYg7LTX/BTt1Dk=; b=UTTLYTFPCvqblENsw+lstnKiGrUGISrg1mvfI1CNgK8A4/uPJBX+c+BVfGnISvIHjy SKeAdaIlFA1YJWwe17Szke2xg8MssrDQFeBc3T7vlc2mKgx74bO+DUmMdyWv6gUEdShf LV7G/R27Y6bw058t33oapqhM0FlcsiaHeN6HGAk8JFPhoG+egrcsxDsioQ+d6XjIBDzC I8UttZea6WWQ9ixKVALUX1Yz9yN59JHYz2nOSM56jJGAkIdbJmGt24obEwepnNSlj05i +sAQxXujOXt7+Ro0pmXDzu6ezsNbLxZB/XYUD70XW5HdQGM95RsSAQxYRXezXEN9VDbj 1pRw== X-Gm-Message-State: ALyK8tIBUpl8PGEf2Li0ofibN+IBMfok8rA6O+KGqnhtQGgmAuJ8poJx+WiDTMt/onGet0YPquMLhORoAZLMLA== X-Received: by 10.202.229.76 with SMTP id c73mr5097788oih.80.1467205960431; Wed, 29 Jun 2016 06:12:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.20.106 with HTTP; Wed, 29 Jun 2016 06:12:39 -0700 (PDT) In-Reply-To: <83fus55l0l.fsf@gnu.org> References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> <83k2hi54ml.fsf@gnu.org> <83fus55l0l.fsf@gnu.org> From: Noam Postavsky Date: Wed, 29 Jun 2016 09:12:39 -0400 X-Google-Sender-Auth: ZqQzrxFM0V9hpuQCSx_gghyZDng Message-ID: Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Wed, Jun 22, 2016 at 10:57 AM, Eli Zaretskii wrote: > In any case, doing that would mean a much larger job, even if it's > possible. E.g., how do you deal with Lisp code that expects > (expand-file-name "~") and (getenv "HOME") to yield the same value? Hmm, so it's easy enough to move setting of both Vprocess_environment and Vinitial_environment before the Windows code starts adding to the environment. And getenv would have to be modified to consult Emacs' environment so that that (expand-file-name "~") and (getenv "HOME") give the same values. But it seems we would then need 2 sets of functions: getenv/setenv and get-subproc-env/set-subproc-env (the latter working on Vprocess_environment only). This feels like a complication with not much benefit. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 29 11:16:29 2016 Received: (at 10980) by debbugs.gnu.org; 29 Jun 2016 15:16:29 +0000 Received: from localhost ([127.0.0.1]:60224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIHE4-00062t-A4 for submit@debbugs.gnu.org; Wed, 29 Jun 2016 11:16:29 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33936) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIHE1-00062a-1n for 10980@debbugs.gnu.org; Wed, 29 Jun 2016 11:16:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIHDu-0004NX-Mt for 10980@debbugs.gnu.org; Wed, 29 Jun 2016 11:16:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIHDm-0004J1-53; Wed, 29 Jun 2016 11:16:10 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1132 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bIHDj-0002oS-O6; Wed, 29 Jun 2016 11:16:08 -0400 Date: Wed, 29 Jun 2016 18:15:44 +0300 Message-Id: <83bn2kvxen.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Wed, 29 Jun 2016 09:12:39 -0400) Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> <83k2hi54ml.fsf@gnu.org> <83fus55l0l.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > From: Noam Postavsky > Date: Wed, 29 Jun 2016 09:12:39 -0400 > Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se > > On Wed, Jun 22, 2016 at 10:57 AM, Eli Zaretskii wrote: > > In any case, doing that would mean a much larger job, even if it's > > possible. E.g., how do you deal with Lisp code that expects > > (expand-file-name "~") and (getenv "HOME") to yield the same value? > > Hmm, so it's easy enough to move setting of both Vprocess_environment > and Vinitial_environment before the Windows code starts adding to the > environment. I'd actually suggest doing it the other way around: move the Windows-specific code in w32.c that pushes these variables into the environment after Vprocess_environment and Vinitial_environment were already computed. That way, we are sure the only affected platform is w32. (Order of initialization at startup matters, so best not to rock the boat there, unless we absolutely have to.) > And getenv would have to be modified to consult Emacs' > environment so that that (expand-file-name "~") and (getenv "HOME") > give the same values. C 'getenv' or Lisp 'getenv'? > But it seems we would then need 2 sets of functions: getenv/setenv and > get-subproc-env/set-subproc-env (the latter working on > Vprocess_environment only). This feels like a complication with not > much benefit. We already have that: there's 'getenv' and 'egetenv' on the C level. And the Lisp 'setenv' is already documented to modify process-environment. So I'm not sure I see the problem (although it's clear that getenv_internal_1 will probably need some Windows specific changes.) From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 29 11:26:12 2016 Received: (at 10980) by debbugs.gnu.org; 29 Jun 2016 15:26:12 +0000 Received: from localhost ([127.0.0.1]:60235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIHNU-0006HT-LU for submit@debbugs.gnu.org; Wed, 29 Jun 2016 11:26:12 -0400 Received: from mail-ob0-f171.google.com ([209.85.214.171]:36809) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIHNS-0006HG-Ph for 10980@debbugs.gnu.org; Wed, 29 Jun 2016 11:26:11 -0400 Received: by mail-ob0-f171.google.com with SMTP id mu6so30471146obc.3 for <10980@debbugs.gnu.org>; Wed, 29 Jun 2016 08:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yHO+tS/UrYHVSwn9udAwqPcGq3ux3tU8LPsI7m/vw8w=; b=axbduhWXcRhXuBKiQXl7CfezwKEuVJHfo0rICSHCJzrmJKtYYNHc4FB3EmGtGChb8T L9XsuCucCE3z2kFrKdZo9Q4a+YlRU3s9HrfZvxcQ8zKUFJcvfER/2Sjb/LMzOuYiSqLa iEVhCTsrXeOGMw8O1DxOouvvS6uIm0/D1kN122qVG9XvRAVElAaMO/P4AvDm+hql3KEb gQMYZE0a7MlOIs4BT98kPCjmqF988hUZWRkjf1PEWj3larwBMCWLJqYsqOr0TbBFNJPM x0bZcwp5T1755sKv79488v49QgYlrFUbv2C7pK9co768kD1l6FNQF1kuQIeS0lDoTBJX 78bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yHO+tS/UrYHVSwn9udAwqPcGq3ux3tU8LPsI7m/vw8w=; b=Zi6B6uo7vHlID0g6wTE4VhUBL5jR4xKVug09ou2TmUtpq6UjtxXZMEzCuCl2jbGIHQ 1g41HqSlwLI7xYBTZuDaGqf8QIicSjmg2dIps3g213RlXN2ytY82GOYN3zkbZNB2+W4x PuV35TjhmR7huWyWvXghsn7Ib2iEZv7ch7t292bAOWAVksNmMeKNzcg6outIpF1/z4+W nHp5q0g/bIePpaf10SBE7rZ+PZFQi9cdfl/HXADSz6NRHqX1a5mYLguG8yKwhrJNyZJB zQojOIL1/Gagu8N7PTSoBP+svYphfVu7hrZc0lz5wzo1U+BX6ebtSwkqeR205prc+5PU OB+w== X-Gm-Message-State: ALyK8tLN0/kb+kXwkHzYil/6bVjfFsif7BFGdc2pGgNw3vc0rXUUyUN72+TBdlipj8ORYlU848QIajliiVoFfQ== X-Received: by 10.202.85.9 with SMTP id j9mr5458240oib.202.1467213964868; Wed, 29 Jun 2016 08:26:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.238 with HTTP; Wed, 29 Jun 2016 08:26:04 -0700 (PDT) In-Reply-To: <83bn2kvxen.fsf@gnu.org> References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> <83k2hi54ml.fsf@gnu.org> <83fus55l0l.fsf@gnu.org> <83bn2kvxen.fsf@gnu.org> From: Noam Postavsky Date: Wed, 29 Jun 2016 11:26:04 -0400 X-Google-Sender-Auth: cD07RoiTxUjXtKPpF_O-UwCe-zU Message-ID: Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Wed, Jun 29, 2016 at 11:15 AM, Eli Zaretskii wrote: >> From: Noam Postavsky >> And getenv would have to be modified to consult Emacs' >> environment so that that (expand-file-name "~") and (getenv "HOME") >> give the same values. > > C 'getenv' or Lisp 'getenv'? Sorry, I meant Lisp getenv. >> But it seems we would then need 2 sets of functions: getenv/setenv and >> get-subproc-env/set-subproc-env (the latter working on >> Vprocess_environment only). This feels like a complication with not >> much benefit. > > We already have that: there's 'getenv' and 'egetenv' on the C level. > And the Lisp 'setenv' is already documented to modify > process-environment. So I'm not sure I see the problem What about a lisp program that expects (expand-file-name "~") and (getenv "HOME") to give the same results after running (setenv "HOME" ) From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 29 11:34:42 2016 Received: (at 10980) by debbugs.gnu.org; 29 Jun 2016 15:34:43 +0000 Received: from localhost ([127.0.0.1]:60244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIHVi-0006VU-Nv for submit@debbugs.gnu.org; Wed, 29 Jun 2016 11:34:42 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38755) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIHVh-0006VH-7k for 10980@debbugs.gnu.org; Wed, 29 Jun 2016 11:34:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIHVW-0000ZU-3p for 10980@debbugs.gnu.org; Wed, 29 Jun 2016 11:34:36 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIHVP-0000Ti-Qt; Wed, 29 Jun 2016 11:34:23 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1173 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bIHVN-0003lo-Jp; Wed, 29 Jun 2016 11:34:22 -0400 Date: Wed, 29 Jun 2016 18:34:00 +0300 Message-Id: <838txovwk7.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Wed, 29 Jun 2016 11:26:04 -0400) Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> <83k2hi54ml.fsf@gnu.org> <83fus55l0l.fsf@gnu.org> <83bn2kvxen.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > From: Noam Postavsky > Date: Wed, 29 Jun 2016 11:26:04 -0400 > Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se > > >> But it seems we would then need 2 sets of functions: getenv/setenv and > >> get-subproc-env/set-subproc-env (the latter working on > >> Vprocess_environment only). This feels like a complication with not > >> much benefit. > > > > We already have that: there's 'getenv' and 'egetenv' on the C level. > > And the Lisp 'setenv' is already documented to modify > > process-environment. So I'm not sure I see the problem > > What about a lisp program that expects (expand-file-name "~") and > (getenv "HOME") to give the same results after running (setenv "HOME" > ) The changes in getenv_internal_1 (or, rather, in getenv_internal) that I mentioned will have to make that happen. It already does something similar. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 29 19:02:33 2016 Received: (at 10980) by debbugs.gnu.org; 29 Jun 2016 23:02:33 +0000 Received: from localhost ([127.0.0.1]:60407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIOV7-0001FF-8e for submit@debbugs.gnu.org; Wed, 29 Jun 2016 19:02:33 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:36156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIOV6-0001F4-DG for 10980@debbugs.gnu.org; Wed, 29 Jun 2016 19:02:32 -0400 Received: by mail-ob0-f170.google.com with SMTP id mu6so47344155obc.3 for <10980@debbugs.gnu.org>; Wed, 29 Jun 2016 16:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yMa+3HDWcc97NX0gIYNG2fAXw2NpZLGqi1YtRBYRvXs=; b=sydLD6TTT0FssoqIEp/Qedlc2ODtZB0TXGhe75njf07YFvhi24jOe9avg53b19t2iC MxpLdcVyS1FtDlLDh9B7qqeSEx/SaudrVd201GwWETKmrgaaXc9lC0pwdFbJIL6wRmN+ dER5zNVGzV8YIbdl+JaIgGswI7HHLMTyxfN9G/KmoZECGVwwphYirmfcxJp+wAPcyfZO nUw71q9j6io+WQBoGkWs5lETCKyp0Clf33jrmxL4aiFr0MjkQ+qCwhZTfjcJuIOiO0PZ qaq2eX5teCnV3vIoxiCsa2XXkqLNz9zWLzZc9ObAjpUKxuPTmZJQSGYyWkukqPSQNw5d bLfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yMa+3HDWcc97NX0gIYNG2fAXw2NpZLGqi1YtRBYRvXs=; b=VrZ43hywwI9z6YiNyvgWzptT3eJiKBl0HmVjDNRv21nv98mNK2ETDQ6T/OCecZnNKQ LjwunjjKzJMR/YDV3SLe65UODuAMWJKo/2+CFYnqbP1CX2viZs7MnwGTJ5Sus4INIBrI gf2Ecen2sY4mHHZpjVJ2+d2lMitwT+1hKrNjAsDxUJSI3qFemjX6vZfozIXGjcTxqsgf v7lp3Xp41Paas1LzMMDlW1pAWkuYY+0oYVRKyW/0rNSoUDgMy76YCKg1q8V2pFvBF6ks 9pil4/0ZKRN+ebL0FKhOlf220m6uOki9umsQpYgdA2T+gHf7jYxE2NV0JueZNu3Uchmb 6NUw== X-Gm-Message-State: ALyK8tJ4sroACTgA9I100/UEzYHNNs+5Qutn7IZPtdKmGiqT6NWI6k9/4HydspTreNa0oV4pG20Mq1cD0Btn2g== X-Received: by 10.157.36.227 with SMTP id z90mr7898646ota.124.1467241346553; Wed, 29 Jun 2016 16:02:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.238 with HTTP; Wed, 29 Jun 2016 16:02:25 -0700 (PDT) In-Reply-To: <838txovwk7.fsf@gnu.org> References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> <83k2hi54ml.fsf@gnu.org> <83fus55l0l.fsf@gnu.org> <83bn2kvxen.fsf@gnu.org> <838txovwk7.fsf@gnu.org> From: Noam Postavsky Date: Wed, 29 Jun 2016 19:02:25 -0400 X-Google-Sender-Auth: g5cKwWw_X-363U3x_Fvbcf7mDoc Message-ID: Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 To: Eli Zaretskii Content-Type: multipart/mixed; boundary=94eb2c04f4f442f533053672bf7b X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --94eb2c04f4f442f533053672bf7b Content-Type: text/plain; charset=UTF-8 On Wed, Jun 29, 2016 at 11:34 AM, Eli Zaretskii wrote: >> From: Noam Postavsky >> Date: Wed, 29 Jun 2016 11:26:04 -0400 >> Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se >> >> >> But it seems we would then need 2 sets of functions: getenv/setenv and >> >> get-subproc-env/set-subproc-env (the latter working on >> >> Vprocess_environment only). This feels like a complication with not >> >> much benefit. >> > >> > We already have that: there's 'getenv' and 'egetenv' on the C level. >> > And the Lisp 'setenv' is already documented to modify >> > process-environment. So I'm not sure I see the problem >> >> What about a lisp program that expects (expand-file-name "~") and >> (getenv "HOME") to give the same results after running (setenv "HOME" >> ) > > The changes in getenv_internal_1 (or, rather, in getenv_internal) that > I mentioned will have to make that happen. It already does something > similar. Ah, I think I missed the idea that changing Vprocess_environment would still affect Emacs' environment (technically, what Emacs thinks its environment is, which has the same effect). Patch attached. --94eb2c04f4f442f533053672bf7b Content-Type: application/octet-stream; name="v2-0001-Keep-w32-environment-settings-internal-only.patch" Content-Disposition: attachment; filename="v2-0001-Keep-w32-environment-settings-internal-only.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iq1hj17e0 RnJvbSAwMDNhODZhMTc3OTY5NGQ5YjVhYWE0NGQ1NTU3ODU0ZGQ5YzJkY2ViIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOb2FtIFBvc3RhdnNreSA8bnBvc3RhdnNAZ21haWwuY29tPgpE YXRlOiBXZWQsIDI5IEp1biAyMDE2IDE4OjUyOjU3IC0wNDAwClN1YmplY3Q6IFtQQVRDSCB2Ml0g S2VlcCB3MzIgZW52aXJvbm1lbnQgc2V0dGluZ3MgaW50ZXJuYWwgb25seQoKKiBzcmMvZW1hY3Mu YyAobWFpbik6IEZvciBXSU5ET1dTTlQgcGxhdGZvcm0sIG1vdmUgaW5pdF9lbnZpcm9ubWVudApj YWxscyBhZnRlciB0aGUgc2V0X2luaXRpYWxfZW52aXJvbm1lbnQgY2FsbC4gIFRoaXMgcHJldmVu dHMgRW1hY3MnCm1vZGlmaWNhdGlvbnMgdG8gdGhlIGVudmlyb25tZW50IGZyb20gY29udGFtaW5h dGluZyBWcHJvY2Vzc19lbnZpcm9ubWVudAphbmQgVmluaXRpYWxfZW52aXJvbm1lbnQgKEJ1ZyAj MTA5ODApLgoqIHNyYy9jYWxscHJvYy5jIChnZXRlbnZfaW50ZXJuYWwpOiBDb25zdWx0IEVtYWNz JyBpbnRlcm5hbCBlbnZpcm9ubWVudAppbiBhcyBhIGZhbGxiYWNrIHRvIFZwcm9jZXNzX2Vudmly b25tZW50IG9uIFdJTkRPV1NOVCBwbGF0Zm9ybXMuCi0tLQogc3JjL2NhbGxwcm9jLmMgfCAxNCAr KysrKysrKysrKysrKwogc3JjL2VtYWNzLmMgICAgfCAyNCArKysrKysrKysrKysrKy0tLS0tLS0t LS0KIDIgZmlsZXMgY2hhbmdlZCwgMjggaW5zZXJ0aW9ucygrKSwgMTAgZGVsZXRpb25zKC0pCgpk aWZmIC0tZ2l0IGEvc3JjL2NhbGxwcm9jLmMgYi9zcmMvY2FsbHByb2MuYwppbmRleCA3MDA4Yjkx Li43ODgwMjM4IDEwMDY0NAotLS0gYS9zcmMvY2FsbHByb2MuYworKysgYi9zcmMvY2FsbHByb2Mu YwpAQCAtMTM3NSw2ICsxMzc1LDIwIEBAIGdldGVudl9pbnRlcm5hbCAoY29uc3QgY2hhciAqdmFy LCBwdHJkaWZmX3QgdmFybGVuLCBjaGFyICoqdmFsdWUsCiAJCQkgVnByb2Nlc3NfZW52aXJvbm1l bnQpKQogICAgIHJldHVybiAqdmFsdWUgPyAxIDogMDsKIAorICAvKiBPbiBXaW5kb3dzIHdlIG1h a2Ugc29tZSBtb2RpZmljYXRpb25zIHRvIEVtYWNzJyBlbnZpcm9tZW50CisgICAgIHdpdGhvdXQg cmVjb3JkaW5nIHRoZW0gaW4gVnByb2Nlc3NfZW52aXJvbm1lbnQuICAqLworI2lmZGVmIFdJTkRP V1NOVAorICB7CisgICAgY2hhciogdG1wdmFsID0gZ2V0ZW52ICh2YXIpOworICAgIGlmICh0bXB2 YWwpCisgICAgICB7CisgICAgICAgICp2YWx1ZSA9IHRtcHZhbDsKKyAgICAgICAgKnZhbHVlbGVu ID0gc3RybGVuKHRtcHZhbCk7CisgICAgICAgIHJldHVybiAxOworICAgICAgfQorICB9CisjZW5k aWYKKwogICAvKiBGb3IgRElTUExBWSB0cnkgdG8gZ2V0IHRoZSB2YWx1ZXMgZnJvbSB0aGUgZnJh bWUgb3IgdGhlIGluaXRpYWwgZW52LiAgKi8KICAgaWYgKHN0cmNtcCAodmFyLCAiRElTUExBWSIp ID09IDApCiAgICAgewpkaWZmIC0tZ2l0IGEvc3JjL2VtYWNzLmMgYi9zcmMvZW1hY3MuYwppbmRl eCBiYjg1NzMzLi5mOTc3Mjg5IDEwMDY0NAotLS0gYS9zcmMvZW1hY3MuYworKysgYi9zcmMvZW1h Y3MuYwpAQCAtMTM1MSwxNiArMTM1MSw2IEBAIFVzaW5nIGFuIEVtYWNzIGNvbmZpZ3VyZWQgd2l0 aCAtLXdpdGgteC10b29sa2l0PWx1Y2lkIGRvZXMgbm90IGhhdmUgdGhpcyBwcm9ibGVtCiAgIGds b2JhbHNfb2ZfZ2ZpbGVub3RpZnkgKCk7CiAjZW5kaWYKIAotI2lmZGVmIFdJTkRPV1NOVAotICBn bG9iYWxzX29mX3czMiAoKTsKLSNpZmRlZiBIQVZFX1czMk5PVElGWQotICBnbG9iYWxzX29mX3cz Mm5vdGlmeSAoKTsKLSNlbmRpZgotICAvKiBJbml0aWFsaXplIGVudmlyb25tZW50IGZyb20gcmVn aXN0cnkgc2V0dGluZ3MuICAqLwotICBpbml0X2Vudmlyb25tZW50IChhcmd2KTsKLSAgaW5pdF9u dHByb2MgKGR1bXBpbmcpOyAvKiBtdXN0IHByZWNlZGUgaW5pdF9lZGl0Zm5zLiAgKi8KLSNlbmRp ZgotCiAjaWZkZWYgSEFWRV9OUwogICAvKiBJbml0aWFsaXplIHRoZSBsb2NhbGUgZnJvbSB1c2Vy IGRlZmF1bHRzLiAgKi8KICAgbnNfaW5pdF9sb2NhbGUgKCk7CkBAIC0xMzc3LDYgKzEzNjcsMjAg QEAgVXNpbmcgYW4gRW1hY3MgY29uZmlndXJlZCB3aXRoIC0td2l0aC14LXRvb2xraXQ9bHVjaWQg ZG9lcyBub3QgaGF2ZSB0aGlzIHByb2JsZW0KICAgaWYgKCEgZHVtcGluZykKICAgICBzZXRfaW5p dGlhbF9lbnZpcm9ubWVudCAoKTsKIAorI2lmZGVmIFdJTkRPV1NOVAorICBnbG9iYWxzX29mX3cz MiAoKTsKKyNpZmRlZiBIQVZFX1czMk5PVElGWQorICBnbG9iYWxzX29mX3czMm5vdGlmeSAoKTsK KyNlbmRpZgorICAvKiBJbml0aWFsaXplIGVudmlyb25tZW50IGZyb20gcmVnaXN0cnkgc2V0dGlu Z3MuICBNYWtlIHN1cmUgdG8gZG8KKyAgICAgdGhpcyBvbmx5IGFmdGVyIGNhbGxpbmcgc2V0X2lu aXRpYWxfZW52aXJvbm1lbnQgc28gdGhhdAorICAgICBWaW5pdGlhbF9lbnZpcm9ubWVudCBhbmQg VnByb2Nlc3NfZW52aXJvbm1lbnQgd2lsbCBjb250YWluIG9ubHkKKyAgICAgdmFyaWFibGVzIGZy b20gdGhlIHBhcmVudCBwcm9jZXNzIHdpdGhvdXQgbW9kaWZpY2F0aW9ucyBmcm9tCisgICAgIEVt YWNzLiAqLworICBpbml0X2Vudmlyb25tZW50IChhcmd2KTsKKyAgaW5pdF9udHByb2MgKGR1bXBp bmcpOyAvKiBtdXN0IHByZWNlZGUgaW5pdF9lZGl0Zm5zLiAgKi8KKyNlbmRpZgorCiAgIC8qIEFJ WCBjcmFzaGVzIGFyZSByZXBvcnRlZCBpbiBzeXN0ZW0gdmVyc2lvbnMgMy4yLjMgYW5kIDMuMi40 CiAgICAgIGlmIHRoaXMgaXMgbm90IGRvbmUuICBEbyBpdCBhZnRlciBzZXRfZ2xvYmFsX2Vudmly b25tZW50IHNvIHRoYXQgd2UKICAgICAgZG9uJ3QgcG9sbHV0ZSBWZ2xvYmFsX2Vudmlyb25tZW50 LiAgKi8KLS0gCjIuNi4yLndpbmRvd3MuMQoK --94eb2c04f4f442f533053672bf7b-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 19:39:28 2016 Received: (at control) by debbugs.gnu.org; 30 Jun 2016 23:39:28 +0000 Received: from localhost ([127.0.0.1]:32892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIlYO-0005WY-AC for submit@debbugs.gnu.org; Thu, 30 Jun 2016 19:39:28 -0400 Received: from mail-io0-f181.google.com ([209.85.223.181]:36478) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bIlYM-0005WM-P1 for control@debbugs.gnu.org; Thu, 30 Jun 2016 19:39:27 -0400 Received: by mail-io0-f181.google.com with SMTP id s63so86493054ioi.3 for ; Thu, 30 Jun 2016 16:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:to:from:subject; bh=NJgEfaRqnO82S4Gyl54h8jQrDoW2RpNCaV0SGpQym/M=; b=aNlkDmsAAlJosT8UNCIe5P6JJSkV3RHFUUX6Fqnkl6++2kf34f0urCSr76S+QbP168 u7+KSxeYQQQ79qbQ8VaDvMGMwT0P1a04iXrRH0Q4MWCSN4hfejOEi8dPQvRJydmagqZF Bgc5UP1ITgA4rwXlrDiHlIA2Q7rmY1g58tucNe/jaVVIBvC4v1x77kw/bJnG8tmJxq88 cafEJ1Vhgxk9red+PwpEQwAp4vxLe8ByV/3NSrRFkvcyfzhpYYQZxNuB+jXbnL6qixnH btltMbHGOzgWLbvDcBMhn9lkEUITYfEQlFym4Q/oiAKofaJVDAEX+ePIDyQmbS4/SIf7 qQbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:message-id:to:from:subject; bh=NJgEfaRqnO82S4Gyl54h8jQrDoW2RpNCaV0SGpQym/M=; b=kH9pT4oEi26SBqNBZ2jLVWPk4X6kY8lG3Wf6viHX6cCHVt3Kafom1a+D2i8QRKfr3l pzlnkq3weiY6enGNJPHVPZn59VKUCgJQqPdqNWOuGS9VmJg4WnZWX87i4TJryPvomQKD onwgofnqpamWL1Ns49S7SuF9ACnuirKHkYngY+BkKs8d+IYbcjmduqlrUqJj/+F5KMlJ GLE4gHjUb0kmZIYWyEgpndGIuXvTiPnJikB/x8/rp+Lo45WrnaXX0vrYJbiP60+v06vS QPcZYODiNqaOOV1MYmWI3BaXoULM/Qtr0ZMAIFkUrizGf8S0Z//jxC5YW10G4rbFzY0y M7uQ== X-Gm-Message-State: ALyK8tJYDNtX3Mp400ZdDhHH5Y6kWQzBU6BlEP4pIpMYCW0LFT8Kc6uqXxB+WCu7Q0amtw== X-Received: by 10.107.11.163 with SMTP id 35mr18618649iol.184.1467329960990; Thu, 30 Jun 2016 16:39:20 -0700 (PDT) Received: from zony (206-188-64-44.cpe.distributel.net. [206.188.64.44]) by smtp.googlemail.com with ESMTPSA id c89sm4970104iod.1.2016.06.30.16.39.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jun 2016 16:39:20 -0700 (PDT) Date: Thu, 30 Jun 2016 19:39:26 -0400 Message-Id: <8737nujlg1.fsf@gmail.com> To: control@debbugs.gnu.org From: npostavs@gmail.com Subject: control message for bug #10980 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) tags 10980 patch From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 09 06:58:11 2016 Received: (at 10980) by debbugs.gnu.org; 9 Jul 2016 10:58:11 +0000 Received: from localhost ([127.0.0.1]:43258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bLpxb-0002hH-HU for submit@debbugs.gnu.org; Sat, 09 Jul 2016 06:58:11 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bLpxZ-0002h2-UE for 10980@debbugs.gnu.org; Sat, 09 Jul 2016 06:58:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLpxR-0000VU-HN for 10980@debbugs.gnu.org; Sat, 09 Jul 2016 06:58:04 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLpx9-0000U5-HD; Sat, 09 Jul 2016 06:57:43 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1517 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bLpx7-00071J-10; Sat, 09 Jul 2016 06:57:41 -0400 Date: Sat, 09 Jul 2016 13:57:33 +0300 Message-Id: <83h9bzgjtu.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: (message from Noam Postavsky on Wed, 29 Jun 2016 19:02:25 -0400) Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> <83k2hi54ml.fsf@gnu.org> <83fus55l0l.fsf@gnu.org> <83bn2kvxen.fsf@gnu.org> <838txovwk7.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.3 (------) > From: Noam Postavsky > Date: Wed, 29 Jun 2016 19:02:25 -0400 > Cc: 10980@debbugs.gnu.org, bo.johansson@lsn.se > > Ah, I think I missed the idea that changing Vprocess_environment would > still affect Emacs' environment (technically, what Emacs thinks its > environment is, which has the same effect). Patch attached. Thanks, please push to master, after fixing the following minor issues: > * src/emacs.c (main): For WINDOWSNT platform, move init_environment > calls after the set_initial_environment call. This prevents Emacs' > modifications to the environment from contaminating Vprocess_environment > and Vinitial_environment (Bug #10980). Code changes in fragments guarded by preprocessor conditionals should be formatted like this: * src/emacs.c (main) [WINDOWSNT]: Move init_environment calls after ... > * src/callproc.c (getenv_internal): Consult Emacs' internal environment > in as a fallback to Vprocess_environment on WINDOWSNT platforms. Same here. > + *valuelen = strlen(tmpval); ^^^^^^^ Please leave a single blank between a function's name and the following opening parenthesis. > + /* Initialize environment from registry settings. Make sure to do > + this only after calling set_initial_environment so that > + Vinitial_environment and Vprocess_environment will contain only > + variables from the parent process without modifications from > + Emacs. */ Please leave 2 blanks between the last period of the comment text and the comment terminator "*/". Bonus points for adding a test for this issue. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 18 17:52:51 2016 Received: (at 10980) by debbugs.gnu.org; 18 Jul 2016 21:52:51 +0000 Received: from localhost ([127.0.0.1]:56069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bPGT5-0001n6-Ju for submit@debbugs.gnu.org; Mon, 18 Jul 2016 17:52:51 -0400 Received: from mail-oi0-f48.google.com ([209.85.218.48]:34267) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bPGT3-0001mr-Ob for 10980@debbugs.gnu.org; Mon, 18 Jul 2016 17:52:50 -0400 Received: by mail-oi0-f48.google.com with SMTP id l65so44483oib.1 for <10980@debbugs.gnu.org>; Mon, 18 Jul 2016 14:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nU3KVnkNb6QT5l17kXUBVmRHiyc1JHnXQog7YixqAaU=; b=JnAhLZ3kIuA9YchTbFAFNuqwmF4eoKNxbbz/yjTyDS/zW88aIfkrMKakSKWLCLVjii YV0EsUx4Z61Q12RjmvqORag/X5cfDjqNdjKFVeMI8r01ffm84x3lsol5/r1y8SCEh5o8 wGbZ6qL8qXHoMPU55X07bE3Da+ZbLeeTIjme+F3Fd21YqlkEOCDPU4HzBt63HH6JY4vQ VEcq6cLFJslsGNvua1OgjdjP0Q54LY8q4H0bM2M2OD4jWz9lcWdoFiWFKcredaaj2Jqd oDtpXI/dHVnmOLrTOMN8nRciJq2VJfx3ZD2CtjT2lQTEpCyLaLLMfj+n4IMCCXkxKOup 6HFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nU3KVnkNb6QT5l17kXUBVmRHiyc1JHnXQog7YixqAaU=; b=LYz1CtMwY2fq6IbFKrvgM0O36wJwhIimEmX+VgvVsIVS0XofNARcZM8kPBlEOhhtm/ eJpl7OH1PjYOaEwWKJb3GFrFLQCCgVqEt1UoWM2bXe1notDX62HmkxQrTAv+cpaRzqpw qPFpQ5QwN3H56UrveMn5kityVUInPcVyzPTExOWK+qYOQArIYIMsDHsGL6FTwqFVmvYk S6UPp4X4Ds9QbtBmgsufswy8Yi6/wTUYFv8FZptI7NzMA3qQpv4Oj/IAyN7nefZZTpOm myJ1k6f0k074wZanFdP9CENblwjqf+Ix1hirwP7urNlAqHm0J/TUGnsi53Cg6NUySIVl XQZA== X-Gm-Message-State: ALyK8tL5TYyXiTZ3w94C8kjiCkk1+sZ61al5Y2F4Rkqeozw7Jf6MLtHcROmGeimJlYwXW/0Xqh5yZFY0FumZEw== X-Received: by 10.202.245.214 with SMTP id t205mr7495387oih.202.1468878764018; Mon, 18 Jul 2016 14:52:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.7.161 with HTTP; Mon, 18 Jul 2016 14:52:43 -0700 (PDT) In-Reply-To: <83h9bzgjtu.fsf@gnu.org> References: <83twh3r5vr.fsf@gnu.org> <83d1na7jtx.fsf@gnu.org> <83k2hi54ml.fsf@gnu.org> <83fus55l0l.fsf@gnu.org> <83bn2kvxen.fsf@gnu.org> <838txovwk7.fsf@gnu.org> <83h9bzgjtu.fsf@gnu.org> From: Noam Postavsky Date: Mon, 18 Jul 2016 17:52:43 -0400 X-Google-Sender-Auth: TF5h0_nRPvFp6vINnAoduxbDNQc Message-ID: Subject: Re: bug#10980: GNU bugs information: logs for bug#10980 To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 10980 Cc: bo.johansson@lsn.se, 10980@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) close 10980 25.2 quit On Sat, Jul 9, 2016 at 6:57 AM, Eli Zaretskii wrote: > Thanks, please push to master, after fixing the following minor > issues: [...] > Bonus points for adding a test for this issue. Done and done, 73f0715d From unknown Fri Jun 20 20:11:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 16 Aug 2016 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 03 21:49:42 2016 Received: (at control) by debbugs.gnu.org; 4 Dec 2016 02:49:42 +0000 Received: from localhost ([127.0.0.1]:51761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDMs2-0004Js-AJ for submit@debbugs.gnu.org; Sat, 03 Dec 2016 21:49:42 -0500 Received: from eggs.gnu.org ([208.118.235.92]:56131) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDMrz-0004JW-G1 for control@debbugs.gnu.org; Sat, 03 Dec 2016 21:49:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDMrs-0001yx-95 for control@debbugs.gnu.org; Sat, 03 Dec 2016 21:49:34 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDMrs-0001yr-52 for control@debbugs.gnu.org; Sat, 03 Dec 2016 21:49:32 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1cDMrr-0005b2-Kh; Sat, 03 Dec 2016 21:49:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22595.33851.293095.70553@gnu.org> Date: Sat, 3 Dec 2016 21:49:31 -0500 From: Glenn Morris To: control@debbugs.gnu.org Subject: Clean up predictable issues due to Emacs version number change X-Debbugs-No-Ack: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.9 (-------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.9 (-------) # Ref: # http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00238.html # http://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00692.html # http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01215.html # Some attempt has been made to check for things backported after the fact. # Erring on the side of a later version number seems preferable anyway. unarchive 10 fixed 10 26.1 notfixed 10 25.2 unarchive 96 fixed 96 26.1 notfixed 96 25.2 unarchive 1149 fixed 1149 26.1 notfixed 1149 25.2 unarchive 1150 fixed 1150 26.1 notfixed 1150 25.2 unarchive 2270 fixed 2270 26.1 notfixed 2270 25.2 unarchive 2405 fixed 2405 26.1 notfixed 2405 25.2 unarchive 2589 fixed 2589 26.1 notfixed 2589 25.2 unarchive 3137 fixed 3137 26.1 notfixed 3137 25.2 unarchive 3393 fixed 3393 26.1 notfixed 3393 25.2 unarchive 4589 fixed 4589 26.1 notfixed 4589 25.2 unarchive 4920 fixed 4920 26.1 notfixed 4920 25.2 unarchive 5001 fixed 5001 26.1 notfixed 5001 25.2 unarchive 5262 fixed 5262 26.1 notfixed 5262 25.2 unarchive 5305 fixed 5305 26.1 notfixed 5305 25.2 unarchive 5314 fixed 5314 26.1 notfixed 5314 25.2 unarchive 5479 fixed 5479 26.1 notfixed 5479 25.2 unarchive 5650 fixed 5650 26.1 notfixed 5650 25.2 unarchive 5661 fixed 5661 26.1 notfixed 5661 25.2 unarchive 5727 fixed 5727 26.1 notfixed 5727 25.2 unarchive 6817 fixed 6817 26.1 notfixed 6817 25.2 unarchive 7385 fixed 7385 26.1 notfixed 7385 25.2 unarchive 7522 fixed 7522 26.1 notfixed 7522 25.2 unarchive 7751 fixed 7751 26.1 notfixed 7751 25.2 unarchive 8634 fixed 8634 26.1 notfixed 8634 25.2 unarchive 8693 fixed 8693 26.1 notfixed 8693 25.2 unarchive 8925 fixed 8925 26.1 notfixed 8925 25.2 unarchive 9342 fixed 9342 26.1 notfixed 9342 25.2 unarchive 9730 fixed 9730 26.1 notfixed 9730 25.2 unarchive 10487 fixed 10487 26.1 notfixed 10487 25.2 unarchive 10540 fixed 10540 26.1 notfixed 10540 25.2 unarchive 10723 fixed 10723 26.1 notfixed 10723 25.2 unarchive 10794 fixed 10794 26.1 notfixed 10794 25.2 unarchive 10980 fixed 10980 26.1 notfixed 10980 25.2 unarchive 11357 fixed 11357 26.1 notfixed 11357 25.2 unarchive 11400 fixed 11400 26.1 notfixed 11400 25.2 unarchive 11788 fixed 11788 26.1 notfixed 11788 25.2 unarchive 12048 fixed 12048 26.1 notfixed 12048 25.2 unarchive 12377 fixed 12377 26.1 notfixed 12377 25.2 unarchive 12378 fixed 12378 26.1 notfixed 12378 25.2 unarchive 12636 fixed 12636 26.1 notfixed 12636 25.2 unarchive 12939 fixed 12939 26.1 notfixed 12939 25.2 unarchive 13269 fixed 13269 26.1 notfixed 13269 25.2 unarchive 13571 fixed 13571 26.1 notfixed 13571 25.2 unarchive 13745 fixed 13745 26.1 notfixed 13745 25.2 unarchive 13949 fixed 13949 26.1 notfixed 13949 25.2 unarchive 14256 fixed 14256 26.1 notfixed 14256 25.2 unarchive 14341 fixed 14341 26.1 notfixed 14341 25.2 unarchive 14484 fixed 14484 26.1 notfixed 14484 25.2 unarchive 14554 fixed 14554 26.1 notfixed 14554 25.2 unarchive 14577 fixed 14577 26.1 notfixed 14577 25.2 unarchive 14687 fixed 14687 26.1 notfixed 14687 25.2 unarchive 14844 fixed 14844 26.1 notfixed 14844 25.2 unarchive 14854 fixed 14854 26.1 notfixed 14854 25.2 unarchive 14915 fixed 14915 26.1 notfixed 14915 25.2 unarchive 14919 fixed 14919 26.1 notfixed 14919 25.2 unarchive 15021 fixed 15021 26.1 notfixed 15021 25.2 unarchive 15047 fixed 15047 26.1 notfixed 15047 25.2 unarchive 15171 fixed 15171 26.1 notfixed 15171 25.2 unarchive 15324 fixed 15324 26.1 notfixed 15324 25.2 unarchive 15445 fixed 15445 26.1 notfixed 15445 25.2 unarchive 15506 fixed 15506 26.1 notfixed 15506 25.2 unarchive 15909 fixed 15909 26.1 notfixed 15909 25.2 unarchive 16136 fixed 16136 26.1 notfixed 16136 25.2 unarchive 16200 fixed 16200 26.1 notfixed 16200 25.2 unarchive 16276 fixed 16276 26.1 notfixed 16276 25.2 unarchive 16294 fixed 16294 26.1 notfixed 16294 25.2 unarchive 16345 fixed 16345 26.1 notfixed 16345 25.2 unarchive 16390 fixed 16390 26.1 notfixed 16390 25.2 unarchive 16406 fixed 16406 26.1 notfixed 16406 25.2 unarchive 16483 fixed 16483 26.1 notfixed 16483 25.2 unarchive 16513 fixed 16513 26.1 notfixed 16513 25.2 unarchive 16579 fixed 16579 26.1 notfixed 16579 25.2 unarchive 16746 fixed 16746 26.1 notfixed 16746 25.2 unarchive 16891 fixed 16891 26.1 notfixed 16891 25.2 unarchive 16904 fixed 16904 26.1 notfixed 16904 25.2 unarchive 17039 fixed 17039 26.1 notfixed 17039 25.2 unarchive 17067 fixed 17067 26.1 notfixed 17067 25.2 unarchive 17119 fixed 17119 26.1 notfixed 17119 25.2 unarchive 17582 fixed 17582 26.1 notfixed 17582 25.2 unarchive 17707 fixed 17707 26.1 notfixed 17707 25.2 unarchive 17716 fixed 17716 26.1 notfixed 17716 25.2 unarchive 17738 fixed 17738 26.1 notfixed 17738 25.2 unarchive 17989 fixed 17989 26.1 notfixed 17989 25.2 unarchive 17999 fixed 17999 26.1 notfixed 17999 25.2 unarchive 18008 fixed 18008 26.1 notfixed 18008 25.2 unarchive 18024 fixed 18024 26.1 notfixed 18024 25.2 unarchive 18026 fixed 18026 26.1 notfixed 18026 25.2 unarchive 18028 fixed 18028 26.1 notfixed 18028 25.2 unarchive 18089 fixed 18089 26.1 notfixed 18089 25.2 unarchive 18092 fixed 18092 26.1 notfixed 18092 25.2 unarchive 18110 fixed 18110 26.1 notfixed 18110 25.2 unarchive 18202 fixed 18202 26.1 notfixed 18202 25.2 unarchive 18203 fixed 18203 26.1 notfixed 18203 25.2 unarchive 18204 fixed 18204 26.1 notfixed 18204 25.2 unarchive 18211 fixed 18211 26.1 notfixed 18211 25.2 unarchive 18279 fixed 18279 26.1 notfixed 18279 25.2 unarchive 18527 fixed 18527 26.1 notfixed 18527 25.2 unarchive 18587 fixed 18587 26.1 notfixed 18587 25.2 unarchive 18634 fixed 18634 26.1 notfixed 18634 25.2 unarchive 18635 fixed 18635 26.1 notfixed 18635 25.2 unarchive 18686 fixed 18686 26.1 notfixed 18686 25.2 unarchive 18692 fixed 18692 26.1 notfixed 18692 25.2 unarchive 18809 fixed 18809 26.1 notfixed 18809 25.2 unarchive 18810 fixed 18810 26.1 notfixed 18810 25.2 unarchive 18829 fixed 18829 26.1 notfixed 18829 25.2 unarchive 19114 fixed 19114 26.1 notfixed 19114 25.2 unarchive 19152 fixed 19152 26.1 notfixed 19152 25.2 unarchive 19209 fixed 19209 26.1 notfixed 19209 25.2 unarchive 19214 fixed 19214 26.1 notfixed 19214 25.2 unarchive 19215 fixed 19215 26.1 notfixed 19215 25.2 unarchive 19255 fixed 19255 26.1 notfixed 19255 25.2 unarchive 19368 fixed 19368 26.1 notfixed 19368 25.2 unarchive 19424 fixed 19424 26.1 notfixed 19424 25.2 unarchive 19497 fixed 19497 26.1 notfixed 19497 25.2 unarchive 19587 fixed 19587 26.1 notfixed 19587 25.2 unarchive 19638 fixed 19638 26.1 notfixed 19638 25.2 unarchive 19722 fixed 19722 26.1 notfixed 19722 25.2 unarchive 19754 fixed 19754 26.1 notfixed 19754 25.2 unarchive 19801 fixed 19801 26.1 notfixed 19801 25.2 unarchive 19851 fixed 19851 26.1 notfixed 19851 25.2 unarchive 20038 fixed 20038 26.1 notfixed 20038 25.2 unarchive 20158 fixed 20158 26.1 notfixed 20158 25.2 unarchive 20181 fixed 20181 26.1 notfixed 20181 25.2 unarchive 20304 fixed 20304 26.1 notfixed 20304 25.2 unarchive 20408 fixed 20408 26.1 notfixed 20408 25.2 unarchive 20460 fixed 20460 26.1 notfixed 20460 25.2 unarchive 20485 fixed 20485 26.1 notfixed 20485 25.2 unarchive 20520 fixed 20520 26.1 notfixed 20520 25.2 unarchive 20654 fixed 20654 26.1 notfixed 20654 25.2 unarchive 20702 fixed 20702 26.1 notfixed 20702 25.2 unarchive 20724 fixed 20724 26.1 notfixed 20724 25.2 unarchive 20878 fixed 20878 26.1 notfixed 20878 25.2 unarchive 21002 fixed 21002 26.1 notfixed 21002 25.2 unarchive 21014 fixed 21014 26.1 notfixed 21014 25.2 unarchive 21024 fixed 21024 26.1 notfixed 21024 25.2 unarchive 21155 fixed 21155 26.1 notfixed 21155 25.2 unarchive 21169 fixed 21169 26.1 notfixed 21169 25.2 unarchive 21171 fixed 21171 26.1 notfixed 21171 25.2 unarchive 21225 fixed 21225 26.1 notfixed 21225 25.2 unarchive 21231 fixed 21231 26.1 notfixed 21231 25.2 unarchive 21252 fixed 21252 26.1 notfixed 21252 25.2 unarchive 21269 fixed 21269 26.1 notfixed 21269 25.2 unarchive 21359 fixed 21359 26.1 notfixed 21359 25.2 unarchive 21427 fixed 21427 26.1 notfixed 21427 25.2 unarchive 21552 fixed 21552 26.1 notfixed 21552 25.2 unarchive 21576 fixed 21576 26.1 notfixed 21576 25.2 unarchive 21577 fixed 21577 26.1 notfixed 21577 25.2 unarchive 21601 fixed 21601 26.1 notfixed 21601 25.2 unarchive 21678 fixed 21678 26.1 notfixed 21678 25.2 unarchive 21679 fixed 21679 26.1 notfixed 21679 25.2 unarchive 21684 fixed 21684 26.1 notfixed 21684 25.2 unarchive 21706 fixed 21706 26.1 notfixed 21706 25.2 unarchive 21759 fixed 21759 26.1 notfixed 21759 25.2 unarchive 21851 fixed 21851 26.1 notfixed 21851 25.2 unarchive 21852 fixed 21852 26.1 notfixed 21852 25.2 unarchive 21853 fixed 21853 26.1 notfixed 21853 25.2 unarchive 21881 fixed 21881 26.1 notfixed 21881 25.2 unarchive 21936 fixed 21936 26.1 notfixed 21936 25.2 unarchive 21962 fixed 21962 26.1 notfixed 21962 25.2 unarchive 22117 fixed 22117 26.1 notfixed 22117 25.2 unarchive 22140 fixed 22140 26.1 notfixed 22140 25.2 unarchive 22170 fixed 22170 26.1 notfixed 22170 25.2 unarchive 22172 fixed 22172 26.1 notfixed 22172 25.2 unarchive 22227 fixed 22227 26.1 notfixed 22227 25.2 unarchive 22315 fixed 22315 26.1 notfixed 22315 25.2 unarchive 22325 fixed 22325 26.1 notfixed 22325 25.2 unarchive 22329 fixed 22329 26.1 notfixed 22329 25.2 unarchive 22348 fixed 22348 26.1 notfixed 22348 25.2 unarchive 22478 fixed 22478 26.1 notfixed 22478 25.2 unarchive 22530 fixed 22530 26.1 notfixed 22530 25.2 unarchive 22531 fixed 22531 26.1 notfixed 22531 25.2 unarchive 22576 fixed 22576 26.1 notfixed 22576 25.2 unarchive 22583 fixed 22583 26.1 notfixed 22583 25.2 unarchive 22586 fixed 22586 26.1 notfixed 22586 25.2 unarchive 22592 fixed 22592 26.1 notfixed 22592 25.2 unarchive 22594 fixed 22594 26.1 notfixed 22594 25.2 unarchive 22595 fixed 22595 26.1 notfixed 22595 25.2 unarchive 22596 fixed 22596 26.1 notfixed 22596 25.2 unarchive 22627 fixed 22627 26.1 notfixed 22627 25.2 unarchive 22632 fixed 22632 26.1 notfixed 22632 25.2 unarchive 22648 fixed 22648 26.1 notfixed 22648 25.2 unarchive 22664 fixed 22664 26.1 notfixed 22664 25.2 unarchive 22720 fixed 22720 26.1 notfixed 22720 25.2 unarchive 22724 fixed 22724 26.1 notfixed 22724 25.2 unarchive 22764 fixed 22764 26.1 notfixed 22764 25.2 unarchive 22799 fixed 22799 26.1 notfixed 22799 25.2 unarchive 22800 fixed 22800 26.1 notfixed 22800 25.2 unarchive 22814 fixed 22814 26.1 notfixed 22814 25.2 unarchive 22824 fixed 22824 26.1 notfixed 22824 25.2 unarchive 22827 fixed 22827 26.1 notfixed 22827 25.2 unarchive 22837 fixed 22837 26.1 notfixed 22837 25.2 unarchive 22841 fixed 22841 26.1 notfixed 22841 25.2 unarchive 22890 fixed 22890 26.1 notfixed 22890 25.2 unarchive 22928 fixed 22928 26.1 notfixed 22928 25.2 unarchive 22940 fixed 22940 26.1 notfixed 22940 25.2 unarchive 22964 fixed 22964 26.1 notfixed 22964 25.2 unarchive 22968 fixed 22968 26.1 notfixed 22968 25.2 unarchive 23020 fixed 23020 26.1 notfixed 23020 25.2 unarchive 23071 fixed 23071 26.1 notfixed 23071 25.2 unarchive 23116 fixed 23116 26.1 notfixed 23116 25.2 unarchive 23139 fixed 23139 26.1 notfixed 23139 25.2 unarchive 23159 fixed 23159 26.1 notfixed 23159 25.2 unarchive 23167 fixed 23167 26.1 notfixed 23167 25.2 unarchive 23262 fixed 23262 26.1 notfixed 23262 25.2 unarchive 23290 fixed 23290 26.1 notfixed 23290 25.2 unarchive 23374 fixed 23374 26.1 notfixed 23374 25.2 unarchive 23390 fixed 23390 26.1 notfixed 23390 25.2 unarchive 23401 fixed 23401 26.1 notfixed 23401 25.2 unarchive 23411 fixed 23411 26.1 notfixed 23411 25.2 unarchive 23459 fixed 23459 26.1 notfixed 23459 25.2 unarchive 23608 fixed 23608 26.1 notfixed 23608 25.2 unarchive 23703 fixed 23703 26.1 notfixed 23703 25.2 unarchive 23730 fixed 23730 26.1 notfixed 23730 25.2 unarchive 23829 fixed 23829 26.1 notfixed 23829 25.2 unarchive 23850 fixed 23850 26.1 notfixed 23850 25.2 unarchive 23863 fixed 23863 26.1 notfixed 23863 25.2 unarchive 23883 fixed 23883 26.1 notfixed 23883 25.2 unarchive 23914 fixed 23914 26.1 notfixed 23914 25.2 unarchive 23949 fixed 23949 26.1 notfixed 23949 25.2 unarchive 23998 fixed 23998 26.1 notfixed 23998 25.2 unarchive 24122 fixed 24122 26.1 notfixed 24122 25.2 unarchive 24133 fixed 24133 26.1 notfixed 24133 25.2 unarchive 24166 fixed 24166 26.1 notfixed 24166 25.2 unarchive 24257 fixed 24257 26.1 notfixed 24257 25.2 unarchive 24308 fixed 24308 26.1 notfixed 24308 25.2 unarchive 24432 fixed 24432 26.1 notfixed 24432 25.2 From unknown Fri Jun 20 20:11:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 01 Jan 2017 12:24:23 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator