From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: $USERPROFILE for $HOME on W32 Date: Fri, 26 Nov 2004 17:03:51 -0500 Message-ID: <873bywuw2n.fsf-monnier+emacs@gnu.org> 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> <01c4d3f9$Blat.v2.2.2$ab0ba100@zahav.net.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1101506701 20767 80.91.229.6 (26 Nov 2004 22:05:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 26 Nov 2004 22:05:01 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 26 23:04:54 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 1CXoD0-0005ZG-00 for ; Fri, 26 Nov 2004 23:04:54 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CXoMG-0002ul-Js for ged-emacs-devel@m.gmane.org; Fri, 26 Nov 2004 17:14:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CXoLy-0002uW-P0 for emacs-devel@gnu.org; Fri, 26 Nov 2004 17:14:10 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CXoLy-0002uK-B9 for emacs-devel@gnu.org; Fri, 26 Nov 2004 17:14:10 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CXoLy-0002uH-8I for emacs-devel@gnu.org; Fri, 26 Nov 2004 17:14:10 -0500 Original-Received: from [209.226.175.74] (helo=tomts20-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CXoC1-00046Q-7O; Fri, 26 Nov 2004 17:03:53 -0500 Original-Received: from alfajor ([67.68.216.58]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041126220352.IXWC2034.tomts20-srv.bellnexxia.net@alfajor>; Fri, 26 Nov 2004 17:03:52 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id AC9532FD52; Fri, 26 Nov 2004 17:03:51 -0500 (EST) Original-To: Eli Zaretskii In-Reply-To: <01c4d3f9$Blat.v2.2.2$ab0ba100@zahav.net.il> (Eli Zaretskii's message of "Fri, 26 Nov 2004 22:50:11 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) 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:30410 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30410 >> 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/. Not necessarily. My HOME dir might get moved at some point. >> 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. No: *you* lost me here. Of course HOME typically never changes during a session. But you were talking about "before dumping" and "after dumping", which is a whole other kettle of fish. > So such changes are never experienced by Emacs users on Posix systems. Probably. I'm pretty sure I tried to change HOME in a running Emacs a couple times (I change my HOME like that occasionally to try and confine some operations to a particular subdir, or to get a program to ignore (and to not change) my config), but I must admit that I can't remember how it affected this Emacs session. >> 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. Sorry I got confused, that's in the VMS-only code. > 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? You might be completely right. As I said it sucks to develop blindfolded. So if someone could actually try the fucking damn patch and help me fix it instead of waste my time about details, ... Or even write a counter patch. >> 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. That's not what I meant. I meant that 2 users can use the same Emacs executable (tho in two different processes), just as under Unix. The lack of support for "other uid" has only minimal impact: basically it prevents ~ from working and that's about it. Big deal. > 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. Why would it matter? Here's a sample session under GNU/Linux. % (unset HOME; emacs) M-x ielm *** Welcome to IELM *** Type (describe-mode) for help. ELISP> (expand-file-name "~/") "/" ELISP> (setenv "HOME" "/u/monnier") "/u/monnier" ELISP> (expand-file-name "~/") "/u/monnier/" ELISP> HOME is not nearly as important as you'd think. The only place where it is needed before reading .emacs seems to be in order to read ~/.Xresources and ~/.Xauthority (although I'd argue that we should only open the X display after reading the .emacs file). Anyway, feel free to provide an alternative patch. Stefan