From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Profiles/manifests-related command line interface enhancements Date: Thu, 24 Oct 2019 17:35:27 -0400 Message-ID: <87v9sdvnb9.fsf@netris.org> References: <87mudrxvs8.fsf@ambrevar.xyz> <87d0emwm95.fsf@netris.org> <87imoewks8.fsf@ambrevar.xyz> <20191024184246.014d810e@scratchpost.org> <87tv7yt3e2.fsf@ambrevar.xyz> <875zkevtel.fsf@netris.org> <87o8y5ucyj.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:42678) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNkma-0006ND-0a for guix-devel@gnu.org; Thu, 24 Oct 2019 17:36:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iNkmY-0000ST-OL for guix-devel@gnu.org; Thu, 24 Oct 2019 17:36:35 -0400 Received: from world.peace.net ([64.112.178.59]:58680) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iNkmY-0000S8-90 for guix-devel@gnu.org; Thu, 24 Oct 2019 17:36:34 -0400 In-Reply-To: <87o8y5ucyj.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Thu, 24 Oct 2019 22:04:52 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: guix-devel@gnu.org Hi Pierre, Pierre Neidhardt writes: > Mark H Weaver writes: > >> It wouldn't be sufficient to remove them. You'd have to restore the >> previous settings. For example, if we remove the settings for PATH, >> MANPATH, etc, without restoring the previous settings, I doubt that you >> would be pleased with the results. > > I don't understand. > Which previous settings? I'm talking about the previous values of the environment variables, as they existed before activating the new profile. > As far as I understand, activating a profile never _removes_ any value > from environment variables. It doesn't remove them, but it overwrites them, thus losing the information of what the previous environment was. Now, it's true that for *most* of those environment variables, the previous value is a suffix of the new value, but that's not always the case. One notable counter-example is GUIX_PROFILE itself, which is simply overwritten. Others include GIT_EXEC_PATH and ASPELL_DICT_DIR. >> It seems to me that the most natural approach to allow restoring the >> previous environment settings is to launch a subshell when you activate >> a profile. That subshell can then simply be exited to restore the >> previous settings. > > I gave the example of EXWM, for which the user would like to change the > profile but a subshell won't do since it won't reflect on the parent > process, Emacs. There's no way to change the environment variable in Emacs without running Emacs lisp code, e.g. by running M-x setenv. In general, every process has a complete copy of its own environment variables, which live in its own address space. When a process launches a child process, it gets to decide what the child's initial environment will be. Usually, but not always, programs pass a copy of their own environment to child processes, and there are convenience functions that make this common case easier. From the kernel's point of view, environment variables are passed to child processes exactly the same way that command-line arguments are, although by convention they are treated differently by user interfaces. There's no mechanism for child processes to ask their parent processes to modify their environment. Each program needs to provide its own mechanism for modifying its internal environment, and most don't even provide such a mechanism. For example, Ratpoison provides a command to modify its own environment (C-t setenv, iirc), but I have no idea how to modify gnome-session's environment. Note that I'm not passing judgement on the merits of your proposals, I'm merely letting you know that they cannot be implemented as envisioned, at least not if I understand correctly. Regards, Mark