GNU bug report logs - #10980
23.4; Variable init_environment incorrectly set

Previous Next

Full log

Message #31 received at 10980 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: bo.johansson <at> lsn.se, 10980 <at> debbugs.gnu.org
Subject: Re: bug#10980: GNU bugs information: logs for bug#10980
Date: Wed, 08 Jun 2016 19:40:24 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Tue, 7 Jun 2016 23:54:17 -0400
> Cc: bo.johansson <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.