From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: $USERPROFILE for $HOME on W32 Date: Fri, 26 Nov 2004 22:50:11 +0200 Message-ID: <01c4d3f9$Blat.v2.2.2$ab0ba100@zahav.net.il> References: <87vfbycsgj.fsf-monnier+emacs@gnu.org> <87mzx69bkn.fsf-monnier+emacs@gnu.org> <01c4d33a$Blat.v2.2.2$dbe68ca0@zahav.net.il> <01c4d3a2$Blat.v2.2.2$f32d2000@zahav.net.il> <87llcobs1i.fsf-monnier+emacs@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: deer.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1101502515 8176 80.91.229.6 (26 Nov 2004 20:55:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 26 Nov 2004 20:55:15 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 26 21:55:05 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CXn7R-0000fB-00 for ; Fri, 26 Nov 2004 21:55:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CXnGh-00007T-Tr for ged-emacs-devel@m.gmane.org; Fri, 26 Nov 2004 16:04:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CXnGG-0008Jg-74 for emacs-devel@gnu.org; Fri, 26 Nov 2004 16:04:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CXnGE-0008IX-3k for emacs-devel@gnu.org; Fri, 26 Nov 2004 16:04:10 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CXnGD-0008IU-QU for emacs-devel@gnu.org; Fri, 26 Nov 2004 16:04:10 -0500 Original-Received: from [192.114.186.24] (helo=legolas.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CXn5g-00077q-R1 for emacs-devel@gnu.org; Fri, 26 Nov 2004 15:53:17 -0500 Original-Received: from zaretski ([80.230.149.126]) by legolas.inter.net.il (MOS 3.5.5-GR) with ESMTP id DEY50376 (AUTH halo1); Fri, 26 Nov 2004 22:53:06 +0200 (IST) Original-To: Stefan Monnier X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 2.2.2 In-reply-to: <87llcobs1i.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Fri, 26 Nov 2004 09:47:50 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:30403 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30403 > From: Stefan Monnier > Date: Fri, 26 Nov 2004 09:47:50 -0500 > Cc: emacs-devel@gnu.org > > Obviously I don't understand what you mean by "before" and "after" dumping. > When I build on my GNU/Linux system, before dump HOME=/u/monnier, and after > dump HOME=/u/fernanda, /u/monnier/, /u/root, /u/guest, ... On the same system as the one where it was dumped and when invoked by the same user, it will stay /u/monnier/. > Huh? The code is not run when startup.el is loaded. It's run when we call > normal-top-level. Right, so with your suggestion, it will get its final correct value even later than I erroneously wrote. > That would screw up anyone who runs an Emacs he hasn't built himself. > I.e. 99% of the users. I think we'd know about it by now. You lost me here: on a Posix system, the value of HOME known to Emacs does not change in the midst of the session startup. It is set outside of Emacs and never changes during the Emacs session. So such changes are never experienced by Emacs users on Posix systems. > > Why insist on doing that when there's a cleaner way? For that matter, is > > there any reason at all to favor doing this in Lisp? I don't think I've > > heard even a single reason in favor; did I miss something? > > I find it much easier to write (file-writable-p "~/.emacs"). And I know it > will not dump a core, even if I mess up badly. So don't mess it up. > >> > This change means that we run this code every time getpwuid is called. > >> Right. Just as we do it on Unix (except on Unix we only do it for HOME > >> and not for SHELL). > > Unix is a different matter. The W32 port emulates a single user, so > > the values are guaranteed to be constant. The right way to impement > > such emulations is to use static variables initialized only once. > > This has nothing to do with single-user or not. On Unix we are also > guaranteed that the uid will not change under us while running Emacs. > And yet, everytime we do getpwnam, we rebuilt its value to obey the current > value of $HOME, in case the user changed it with (setenv "HOME" foo). > Read the source. Wait a minute, I always thought setenv only modifies the value of the variable for the subprocesses, not the value seen by Emacs. It modifies process-environment, but does not call setenv or putenv in C to modify the environment of the Emacs process, right? So (setenv "HOME" foo) should not matter for the value of pw_dir, right? Hmm... that probably means that, since your suggestion is based on using setenv, it is not going to work, i.e. it will not change the value of HOME as known to Emacs itself. Am I missing something? > And BTW, W32 is not very different w.r.t single or multi user. The GUI > makes it difficult to have more than one person logged in at the same time, > but other than that it's basically just the same. Not as far as getpwuid is concerned: the code is written to support only one user ID: the one we saw at Emacs startup. Read the source. > My opinion is that something should be done in C only if it can't be done in > elisp, or if it's inconvenient to do it in elisp, or if doing it in elisp is > too costly performancewise. There's at least one other situation where a C implementation is appropriate: when things should be done as early in the Emacs startup process as possible, because they might affect the later parts, i.e. some of the init_* functions. In the case in point, we need to set HOME very early, because the C part of the session initialization needs to see the same value of HOME as the Lisp code and all the rest of the session will. This is so because we want to pretend that the value of HOME came from outside Emacs.