$USERPROFILE for $HOME on W32

$USERPROFILE for $HOME on W32

[Stefan Monnier]

To follow up on the thread, here is a suggested patch.
Any objection?
If anybody wants to install it (with or without adjustments), please feel
free to do it: I'd rather not spend any more time on this.


        Stefan


--- startup.el	17 oct 2004 18:58:12 -0400	1.333
+++ startup.el	22 nov 2004 01:23:05 -0500	
@@ -340,6 +340,14 @@
   (if command-line-processed
       (message "Back to top level.")
     (setq command-line-processed t)
+    ;; On W32, try to use $USERPROFILE if $HOME isn't properly set.
+    (when (and (memq system-type '(windows-nt))
+	       (equal (getenv "HOME") "C:/")
+	       (not (file-exists-p "~/.emacs"))
+	       (not (file-exists-p "~/_emacs"))
+	       (getenv "USERPROFILE")
+	       (file-writable-p (getenv "USERPROFILE")))
+      (setenv "HOME" (getenv "USERPROFILE")))
     ;; Give *Messages* the same default-directory as *scratch*,
     ;; just to keep things predictable.
     (let ((dir default-directory))

Re: $USERPROFILE for $HOME on W32

[Jason Rumney]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> To follow up on the thread, here is a suggested patch.
> Any objection?

I'd rather put the code in init_environment() in w32.c, and keep all
hacking of environment variables in one place.


> --- startup.el	17 oct 2004 18:58:12 -0400	1.333
> +++ startup.el	22 nov 2004 01:23:05 -0500	
> @@ -340,6 +340,14 @@
>    (if command-line-processed
>        (message "Back to top level.")
>      (setq command-line-processed t)
> +    ;; On W32, try to use $USERPROFILE if $HOME isn't properly set.
> +    (when (and (memq system-type '(windows-nt))
> +	       (equal (getenv "HOME") "C:/")
> +	       (not (file-exists-p "~/.emacs"))
> +	       (not (file-exists-p "~/_emacs"))
> +	       (getenv "USERPROFILE")
> +	       (file-writable-p (getenv "USERPROFILE")))
> +      (setenv "HOME" (getenv "USERPROFILE")))
>      ;; Give *Messages* the same default-directory as *scratch*,
>      ;; just to keep things predictable.
>      (let ((dir default-directory))

Re: $USERPROFILE for $HOME on W32

[Stefan Monnier]

>> To follow up on the thread, here is a suggested patch.
>> Any objection?

> I'd rather put the code in init_environment() in w32.c, and keep all
> hacking of environment variables in one place.

Well, I'd myself rather move it all into elisp where we have a lot
more flexibility.  It's not like speed is important there.

But if you want to write it in C, go for it, I myself just want to get the
behavior implemented so I stop getting complaints from users around me,


        Stefan

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 22 Nov 2004 01:26:51 -0500
> 
> +    ;; On W32, try to use $USERPROFILE if $HOME isn't properly set.
> +    (when (and (memq system-type '(windows-nt))

Shouldn't this take effect for the Cygwin build as well?

Re: $USERPROFILE for $HOME on W32

[Stefan Monnier]

>> +    ;; On W32, try to use $USERPROFILE if $HOME isn't properly set.
>> +    (when (and (memq system-type '(windows-nt))

> Shouldn't this take effect for the Cygwin build as well?

Quite possible, but I only have experience with `windows-nt'.
Note that I used the `memq' form to make it trivial to add other cases like
cygwin or ms-dos.


        Stefan

Re: $USERPROFILE for $HOME on W32

[Jason Rumney]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Mon, 22 Nov 2004 01:26:51 -0500
>> 
>> +    ;; On W32, try to use $USERPROFILE if $HOME isn't properly set.
>> +    (when (and (memq system-type '(windows-nt))
>
> Shouldn't this take effect for the Cygwin build as well?

I may be wrong, but I think HOME will always be defined under Cygwin.

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> From: Jason Rumney <jasonr@gnu.org>
> Date: Tue, 23 Nov 2004 08:30:35 +0000
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Date: Mon, 22 Nov 2004 01:26:51 -0500
> >> 
> >> +    ;; On W32, try to use $USERPROFILE if $HOME isn't properly set.
> >> +    (when (and (memq system-type '(windows-nt))
> >
> > Shouldn't this take effect for the Cygwin build as well?
> 
> I may be wrong, but I think HOME will always be defined under Cygwin.

I thought about that, but just wasn't sure.  Someone who knows more
about Cygwin should tell, I guess.

In any case, if we suspect $HOME is always set on Cygwin, adding it to
the list won't do any harm.

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 22 Nov 2004 11:47:48 -0500
> 
> Note that I used the `memq' form to make it trivial to add other cases like
> cygwin or ms-dos.

ms-dos does not need to be added, as the MS-DOS port already has the
necessary magic to always have $HOME defined (around line 4478 in
msdos.c).  The user-level consequences of that are described near the
end of the node `(emacs)MS-DOS File Names'.

But having memq there is good anyway, IMHO.  Thanks.

Re: $USERPROFILE for $HOME on W32

[Jason Rumney]

"Eli Zaretskii" <eliz@gnu.org> writes:

> In any case, if we suspect $HOME is always set on Cygwin, adding it to
> the list won't do any harm.

It will if $HOME is set to "C:/" deliberately and .emacs does not
exist yet. This applies on the native Windows build as well, which is
another reason why it would be better to do this in the same place as
HOME is set to C:/ (whether we move this to C, or move the current
code to Lisp, I have no preference) and do it if HOME is unset rather
than if HOME is set to "C:/".

I don't think Cygwin has code to default HOME to "C:/" (the cygwin path
would be /cygdrive/c/ anyway), if it does then it should probably be
"/home" or "/home/$USER" anyway, making it $USERPROFILE does not fit
with the Cygwin way of doing things.

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Jason Rumney <jasonr@gnu.org>
> Date: Tue, 23 Nov 2004 20:47:53 +0000
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> > In any case, if we suspect $HOME is always set on Cygwin, adding it to
> > the list won't do any harm.
> 
> It will if $HOME is set to "C:/" deliberately and .emacs does not
> exist yet. This applies on the native Windows build as well

Exactly: adding Cygwin to the list will not do any harm beyond what
the suggested patch already does for the native build.

Anyway, setting HOME to "C:/" is silly, IMHO.

> another reason why it would be better to do this in the same place as
> HOME is set to C:/

I agree.

> I don't think Cygwin has code to default HOME to "C:/"

The Cygwin build runs the Unix code, so there's no setting of HOME
anywhere in it.

Re: $USERPROFILE for $HOME on W32

[John Paul Wallington]

> To follow up on the thread, here is a suggested patch.
> Any objection?

Disclaimer: I don't know much about Windows.  I think that MIT/GNU
Scheme Edwin uses HOMEDRIVE and HOMEPATH rather than USERPROFILE.  I
noticed that on an NT 3.51 system HOMEDRIVE and HOMEPATH have sane
values but USERPROFILE isn't defined.  On an XP system USERPROFILE is
the same as concatenating HOMEDRIVE and HOMEPATH.

Perhaps we could fall back on using HOMEDRIVE and HOMEPATH if
USERPROFILE doesn't exist or isn't writable ?

Re: $USERPROFILE for $HOME on W32

[Stefan Monnier]

Here is a new patch.  Could people try it out and tell me if it works?
And tell me how to fix it (I can't try it out, I wish someone could help me
out, really, because coding and debugging blindly like that isn't much fun).


        Stefan


Index: src/w32.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32.c,v
retrieving revision 1.89
diff -u -r1.89 w32.c
--- src/w32.c	19 Oct 2004 19:08:58 -0000	1.89
+++ src/w32.c	25 Nov 2004 16:03:01 -0000
@@ -1,5 +1,5 @@
 /* Utility and Unix shadow routines for GNU Emacs on the Microsoft W32 API.
-   Copyright (C) 1994, 1995, 2000, 2001 Free Software Foundation, Inc.
+   Copyright (C) 1994, 1995, 2000, 2001, 2004  Free Software Foundation, Inc.
 
 This file is part of GNU Emacs.
 
@@ -424,7 +424,12 @@
 getpwuid (int uid)
 {
   if (uid == the_passwd.pw_uid)
-    return &the_passwd;
+    {
+      /* Set dir and shell from environment variables. */
+      strcpy (the_passwd.pw_dir, getenv ("HOME"));
+      strcpy (the_passwd.pw_shell, getenv ("SHELL"));
+      return &the_passwd;
+    }
   return NULL;
 }
 
@@ -531,16 +536,6 @@
       the_passwd.pw_gid = 123;
     }
 
-  /* Ensure HOME and SHELL are defined. */
-  if (getenv ("HOME") == NULL)
-    abort ();
-  if (getenv ("SHELL") == NULL)
-    abort ();
-
-  /* Set dir and shell from environment variables. */
-  strcpy (the_passwd.pw_dir, getenv ("HOME"));
-  strcpy (the_passwd.pw_shell, getenv ("SHELL"));
-
   if (token)
     CloseHandle (token);
 }
@@ -949,11 +944,9 @@
       char * def_value;
     } env_vars[] =
     {
-      {"HOME", "C:/"},
       {"PRELOAD_WINSOCK", NULL},
       {"emacs_dir", "C:/emacs"},
       {"EMACSLOADPATH", "%emacs_dir%/site-lisp;%emacs_dir%/../site-lisp;%emacs_dir%/lisp;%emacs_dir%/leim"},
-      {"SHELL", "%emacs_dir%/bin/cmdproxy.exe"},
       {"EMACSDATA", "%emacs_dir%/etc"},
       {"EMACSPATH", "%emacs_dir%/bin"},
       /* We no longer set INFOPATH because Info-default-directory-list
Index: lisp/w32-fns.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/w32-fns.el,v
retrieving revision 1.54
diff -u -r1.54 w32-fns.el
--- lisp/w32-fns.el	30 May 2004 21:19:06 -0000	1.54
+++ lisp/w32-fns.el	25 Nov 2004 16:03:01 -0000
@@ -195,6 +195,28 @@
   (goto-char (point-min)))
 
 
+
+(defun w32-early-setenv ()
+  "Setup sane default values for important environment variables."
+  (unless (getenv "HOME")
+    ;; Try to use $USERPROFILE if $HOME isn't properly set.
+    (setenv "HOME"
+	    (cond
+	     ((or (file-readable-p "C:/.emacs") (file-readable-p "C:/_emacs"))
+	      ;; Backward compatibility with old default of "C:/".
+	      "C:/")
+	     ((and (getenv "USERPROFILE")
+		   (file-writable-p (getenv "USERPROFILE")))
+	      (getenv "USERPROFILE"))
+	     ((and (getenv "HOMEPATH") (getenv "HOMEDRIVE")
+		   (file-writable-p
+		    (expand-file-name (getenv "HOMEPATH") (getenv "HOMEDRIVE"))))
+	      (expand-file-name (getenv "HOMEPATH") (getenv "HOMEDRIVE")))
+	     (t "C:/"))))
+  (unless (getenv "SHELL")
+    ;; When is %emacs_dir% expanded?  Should I do it here?
+    (setenv "SHELL" "%emacs_dir%/bin/cmdproxy.exe")))
+
 ;;; Setup Info-default-directory-list to include the info directory
 ;;; near where Emacs executable was installed.  We used to set INFOPATH,
 ;;; but when this is set Info-default-directory-list is ignored.  We
@@ -454,5 +476,5 @@
 (setq interprogram-paste-function 'x-get-selection-value)
 
 
-;;; arch-tag: c49b48cc-0f4f-454f-a274-c2dc34815e14
+;; arch-tag: c49b48cc-0f4f-454f-a274-c2dc34815e14
 ;;; w32-fns.el ends here
Index: lisp/startup.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v
retrieving revision 1.333
diff -u -r1.333 startup.el
--- lisp/startup.el	17 Oct 2004 06:56:40 -0000	1.333
+++ lisp/startup.el	25 Nov 2004 16:03:01 -0000
@@ -340,6 +340,9 @@
   (if command-line-processed
       (message "Back to top level.")
     (setq command-line-processed t)
+    (when (memq system-type '(windows-nt))
+      ;; Set HOME and SHELL if necessary.
+      (w32-early-setenv))
     ;; Give *Messages* the same default-directory as *scratch*,
     ;; just to keep things predictable.
     (let ((dir default-directory))
@@ -1728,5 +1731,5 @@
       (setq file (replace-match "/" t t file)))
     file))
 
-;;; arch-tag: 7e294698-244d-4758-984b-4047f887a5db
+;; arch-tag: 7e294698-244d-4758-984b-4047f887a5db
 ;;; startup.el ends here

Re: $USERPROFILE for $HOME on W32

[Jason Rumney]

Stefan Monnier wrote:

>Here is a new patch.  Could people try it out and tell me if it works?
>And tell me how to fix it (I can't try it out, I wish someone could help me
>out, really, because coding and debugging blindly like that isn't much fun).
>  
>
I haven't had time yet to test the whole patch, but I did a quick test 
of the bit you were'nt sure of:

>+  (unless (getenv "SHELL")
>+    ;; When is %emacs_dir% expanded?  Should I do it here?
>+    (setenv "SHELL" "%emacs_dir%/bin/cmdproxy.exe")))
>+
>  
>

(setenv "TESTSHELL" "%emacs_dir%/bin/cmdproxy.exe")
"%emacs_dir%/bin/cmdproxy.exe"
(getenv "SHELL")
"C:/emacs/bin/cmdproxy.exe"
(getenv "TESTSHELL")
"%emacs_dir%/bin/cmdproxy.exe"


So I think that will need to be:

   (setenv "SHELL" (concat (getenv "emacs_dir") "/bin/cmdproxy.exe"))

Re: $USERPROFILE for $HOME on W32

[Stefan]

> I haven't had time yet to test the whole patch, but I did a quick test of
> the bit you were'nt sure of:

Thanks (tho it's not like I'm sure of the rest either ;-).

>    (setenv "SHELL" (concat (getenv "emacs_dir") "/bin/cmdproxy.exe"))

Hmm... OK.
Does anyone know where the %emacs_dir% expansion takes place in the current
code (if you look at my patch you'll note that in w32.c the current code
(which my patch removes) gives "%emacs_dir%/bin/cmdproxy.exe" as default for
SHELL) ?


        Stefan

Re: $USERPROFILE for $HOME on W32

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> @@ -424,7 +424,12 @@
>  getpwuid (int uid)
>  {
>    if (uid == the_passwd.pw_uid)
> -    return &the_passwd;
> +    {
> +      /* Set dir and shell from environment variables. */
> +      strcpy (the_passwd.pw_dir, getenv ("HOME"));

What if strlen (getenv ("HOME")) >= sizeof (the_passwd.pw_dir)?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: $USERPROFILE for $HOME on W32

[Stefan]

>> +      /* Set dir and shell from environment variables. */
>> +      strcpy (the_passwd.pw_dir, getenv ("HOME"));

> What if strlen (getenv ("HOME")) >= sizeof (the_passwd.pw_dir)?

Well, tough!
This code is not new: it's just moved from one place to another so it's not
a new problem.


        Stefan

Re: $USERPROFILE for $HOME on W32

[Andreas Schwab]

Stefan <monnier@iro.umontreal.ca> writes:

>>> +      /* Set dir and shell from environment variables. */
>>> +      strcpy (the_passwd.pw_dir, getenv ("HOME"));
>
>> What if strlen (getenv ("HOME")) >= sizeof (the_passwd.pw_dir)?
>
> Well, tough!
> This code is not new: it's just moved from one place to another so it's not
> a new problem.

I know, but it is still worth to be fixed.  I don't see why it can't be
dynamically allocated in the first place.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> From: Stefan <monnier@iro.umontreal.ca>
> Date: Thu, 25 Nov 2004 12:45:48 -0500
> Cc: emacs-devel@gnu.org, Jason Rumney <jasonr@gnu.org>
> 
> >> +      /* Set dir and shell from environment variables. */
> >> +      strcpy (the_passwd.pw_dir, getenv ("HOME"));
> 
> > What if strlen (getenv ("HOME")) >= sizeof (the_passwd.pw_dir)?
> 
> Well, tough!
> This code is not new: it's just moved from one place to another so it's not
> a new problem.

Can you (or someone else) look at the w32 system headers and see how
struct passwd is defined there?  I looked at two implementations
(DJGPP and glibc on Debian GNU/Linux), and they both define pw_dir and
pw_shell as `char *'.  So using strcpy here might mean a disaster, as
no memory could have been allocated for them; I'd use strdup instead.

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> From: Stefan <monnier@iro.umontreal.ca>
> Date: Thu, 25 Nov 2004 11:54:51 -0500
> Cc: emacs-devel@gnu.org
> 
> Does anyone know where the %emacs_dir% expansion takes place in the current
> code

It's on line 1005 of w32.c and again on line 1029 there (the former
for running Emacs from a standard installation of the binary package,
the latter for running from the build directory).  The function that
does that is init_environment.

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 25 Nov 2004 11:00:39 -0500
> Cc: emacs-devel@gnu.org
> 
> Here is a new patch.  Could people try it out and tell me if it works?
> And tell me how to fix it

I still think, like Jason, that all the environment variables frobbing
on w32 should be in w32.c:init_environment, not in Lisp.  Moving it to
Lisp means, e.g., that temacs will have different ideas about HOME
etc. than the dumped Emacs, which I think might confuse someone some
day.  See below for another reason.

>  getpwuid (int uid)
>  {
>    if (uid == the_passwd.pw_uid)
> -    return &the_passwd;
> +    {
> +      /* Set dir and shell from environment variables. */
> +      strcpy (the_passwd.pw_dir, getenv ("HOME"));
> +      strcpy (the_passwd.pw_shell, getenv ("SHELL"));
> +      return &the_passwd;
> +    }
>    return NULL;
>  }

This change means that we run this code every time getpwuid is called.
That's too excessive, I think, and could be avoided if all the
environment frobbing were done in C.

Re: $USERPROFILE for $HOME on W32

[Jason Rumney]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Does anyone know where the %emacs_dir% expansion takes place in the current
>> code
>
> It's on line 1005 of w32.c and again on line 1029 there (the former
> for running Emacs from a standard installation of the binary package,
> the latter for running from the build directory).  The function that
> does that is init_environment.

Line 1055 is where the actual expansion takes place in both cases.

Re: $USERPROFILE for $HOME on W32

[Stefan Monnier]

> Lisp means, e.g., that temacs will have different ideas about HOME
> etc. than the dumped Emacs, which I think might confuse someone some

Huh?  Of course HOME is different before and after the dump.
How could it be otherwise?

>> getpwuid (int uid)
>> {
>> if (uid == the_passwd.pw_uid)
>> -    return &the_passwd;
>> +    {
>> +      /* Set dir and shell from environment variables. */
>> +      strcpy (the_passwd.pw_dir, getenv ("HOME"));
>> +      strcpy (the_passwd.pw_shell, getenv ("SHELL"));
>> +      return &the_passwd;
>> +    }
>> return NULL;
>> }

> 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).

> That's too excessive, I think,

Doesn't seem to bother people on Unix.

> and could be avoided if all the
> environment frobbing were done in C.

There are many ways to avoid such repetition if it's a problem.
Moving the initialization to C is one way among many others, so I don't
think it's a particularly compelling reason.


        Stefan

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> Cc: jasonr@gnu.org, emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 25 Nov 2004 18:43:36 -0500
> 
> > Lisp means, e.g., that temacs will have different ideas about HOME
> > etc. than the dumped Emacs, which I think might confuse someone some
> 
> Huh?  Of course HOME is different before and after the dump.
> How could it be otherwise?

We are emulating a Posix system where HOME's value is something
determined outside Emacs.  If you set HOME in init_environment, it
will be the same before and after dumping, as it is on a Posix system,
since init_environment is called unconditionally in the W32 port, and
called very early in the initialization process, way before the Lisp
interpreter is started and any application-level code runs.

The way you suggested to do it, not only will it be different before
and after the dumping, but it also changes its value in the middle of
loadup, because startup.el is loaded after many other Lisp files.
Such a change is unexpected by any reasonable Emacs hacker, and could
cost someone several hours of useless ``debugging'', or even real bugs
if some preloaded Lisp file references HOME's value.  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?

> > 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.

> > and could be avoided if all the
> > environment frobbing were done in C.
> 
> There are many ways to avoid such repetition if it's a problem.
> Moving the initialization to C is one way among many others, so I don't
> think it's a particularly compelling reason.

It's just one of several minor reasons.  I never said your suggestion
was a catastrophe, only that there's a slightly better way.  But if
what I said, and the fact that Jason also preferred doing that in C,
don't convince you, then probably nothing will; I give up.

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: Thu, 25 Nov 2004 22:46:45 +0000
> Cc: Stefan <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> Line 1055 is where the actual expansion takes place in both cases.

Perhaps I misunderstood what Stefan was asking.  I thought he wanted
to know where's the value of emacs_dir pushed into the environment,
not where its value is substitited in the other variables.  Sorry if I
misunderstood.

Re: $USERPROFILE for $HOME on W32

[Stefan Monnier]

>> > Lisp means, e.g., that temacs will have different ideas about HOME
>> > etc. than the dumped Emacs, which I think might confuse someone some
>> 
>> Huh?  Of course HOME is different before and after the dump.
>> How could it be otherwise?

> We are emulating a Posix system where HOME's value is something
> determined outside Emacs.  If you set HOME in init_environment, it
> will be the same before and after dumping, as it is on a Posix system,
> since init_environment is called unconditionally in the W32 port, and
> called very early in the initialization process, way before the Lisp
> interpreter is started and any application-level code runs.

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, ...

> The way you suggested to do it, not only will it be different before
> and after the dumping, but it also changes its value in the middle of
> loadup, because startup.el is loaded after many other Lisp files.

Huh?  The code is not run when startup.el is loaded.  It's run when we call
normal-top-level.

> Such a change is unexpected by any reasonable Emacs hacker, and could
> cost someone several hours of useless ``debugging'', or even real bugs
> if some preloaded Lisp file references HOME's value.

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.

> 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.

>> > 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.
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.

> It's just one of several minor reasons.  I never said your suggestion
> was a catastrophe, only that there's a slightly better way.  But if
> what I said, and the fact that Jason also preferred doing that in C,
> don't convince you, then probably nothing will; I give up.

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.
I don't think any of those 3 cases applies here.


        Stefan

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> 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.

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> Date: Thu, 25 Nov 2004 23:45:18 +0200
> From: "Eli Zaretskii" <eliz@gnu.org>
> Cc: jasonr@gnu.org, emacs-devel@gnu.org
> 
> > From: Stefan <monnier@iro.umontreal.ca>
> > Date: Thu, 25 Nov 2004 12:45:48 -0500
> > Cc: emacs-devel@gnu.org, Jason Rumney <jasonr@gnu.org>
> > 
> > >> +      /* Set dir and shell from environment variables. */
> > >> +      strcpy (the_passwd.pw_dir, getenv ("HOME"));
> > 
> > > What if strlen (getenv ("HOME")) >= sizeof (the_passwd.pw_dir)?
> > 
> > Well, tough!
> > This code is not new: it's just moved from one place to another so it's not
> > a new problem.
> 
> Can you (or someone else) look at the w32 system headers and see how
> struct passwd is defined there?

Silly me: it's defined on w32.c, right there.  The pw_dir etc. struct
members are defined as fixed-size strings, and the sizes are all 256
bytes, including the terminating null.  So I think, at least that
should be changed to 261, since the longest file name supported by
Windows is 260 characters.

Re: $USERPROFILE for $HOME on W32

[Stefan Monnier]

>> 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 ~<user> 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

Re: $USERPROFILE for $HOME on W32

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

> Silly me: it's defined on w32.c, right there.  The pw_dir etc. struct
> members are defined as fixed-size strings, and the sizes are all 256
> bytes, including the terminating null.  So I think, at least that
> should be changed to 261, since the longest file name supported by
> Windows is 260 characters.

Any fixed length would be wrong, IMHO.  Can't this just be dynamically
allocated?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, jasonr@gnu.org, emacs-devel@gnu.org
> From: Andreas Schwab <schwab@suse.de>
> Date: Sat, 27 Nov 2004 00:42:07 +0100
> 
> Any fixed length would be wrong, IMHO.  Can't this just be dynamically
> allocated?

Any _arbitrary_ fixed length is wrong.  But if the filesystem supports
at most FILENAME_MAX-long file names, then using FILENAME_MAX for
strings that hold file names is not arbitrary.  Likewise, if we know
what is the maximum length of a Windows user name, we could use that
value as the size of the pw_name member.

But using strdup would also be okay, IMHO, and would avoid the need
for looking up the OS limits for each member.

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 26 Nov 2004 17:03:51 -0500
> 
> > 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.

Yes, but that's hardly a common situation, let alone something you
expect to be done behind your back.

> 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.

I was thinking about an Emacs developer who debugs temacs and/or
dumped emacs on the same machine and under the same user name.  Having
HOME with different values in each case is an unexpected subtlety in
such a situation.

> > 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?

It _could_ matter; I didn't check that the current sources actually
reference $HOME in the initialization code.  But they most certainly
could, and I think we need to come up with a method of setting $HOME
that has the least probability of introducing a bug if the
initialization code ever references the value of HOME.  Setting its
value as close as possible to the first line of `main' comes closer to
achieving this goal than doing it as part of top-level.

> Anyway, feel free to provide an alternative patch.

Below.  It's also untested (I don't have a working Windows development
environment to try it), so caveat emptor.

If the patch is accepted, there are a few issues with this patch that
I think need to be discussed:

 . Use of R_OK to probe .emacs usability.  The code as written does
   what Stefan's Lisp implementation did, but I'm not sure it is
   correct to settle for .emacs being readable.  Shouldn't we check if
   it is writable?  Suppose that C:/.emacs exists, but is from another
   user of the same system, for example.

 . Use of W_OK to probe whether a directory is usable.  On Windows,
   the read-only bit of a directory does not prevent a user from
   creating files in that directory.  So it might be enough to check
   for D_OK alone.

 . The exact environment variables to check.  I think I saw HOMEDRIVE
   and HOMEPATH spelled on Windows XP as HomeDrive and HomePath.  If
   the Windows' version of `getenv' is case-sensitive, the code below
   should try both spellings.


--- emacs/src/w32.c~	2004-10-23 23:04:50.000000000 +0200
+++ emacs/src/w32.c	2004-11-27 13:35:14.000000000 +0200
@@ -371,8 +371,8 @@ getloadavg (double loadavg[], int nelem)
 static char the_passwd_name[PASSWD_FIELD_SIZE];
 static char the_passwd_passwd[PASSWD_FIELD_SIZE];
 static char the_passwd_gecos[PASSWD_FIELD_SIZE];
-static char the_passwd_dir[PASSWD_FIELD_SIZE];
-static char the_passwd_shell[PASSWD_FIELD_SIZE];
+static char the_passwd_dir[MAX_PATH];
+static char the_passwd_shell[MAX_PATH];
 
 static struct passwd the_passwd =
 {
@@ -896,6 +896,7 @@ w32_get_resource (key, lpdwtype)
 
 char *get_emacs_configuration (void);
 extern Lisp_Object Vsystem_configuration;
+int sys_access (const char *, int);
 
 void
 init_environment (char ** argv)
@@ -1033,6 +1034,39 @@ init_environment (char ** argv)
 	}
     }
 
+    /* Compute the default value for HOME.  Maintain compatibility
+       with previous setup of defaulting to C:/ if there's already a
+       usable .emacs in there.  */
+    if (sys_access ("C:/.emacs", R_OK) != 0
+	&& sys_access ("C:/_emacs", R_OK) != 0)
+      {
+	char *userprofile = getenv ("USERPROFILE");
+	char *homepath = getenv ("HOMEPATH");
+	char *homedrive = getenv ("HOMEDRIVE");
+
+	for (i = 0; i < (sizeof (env_vars) / sizeof (env_vars[0])); i++)
+	  {
+	    if (strcmp (env_vars[i].name, "HOME") == 0)
+	      break;
+	  }
+
+	/* Default to %USERPROFILE% if set and accessible, otherwise
+	   to %HOMEDRIVE%/%HOMEPATH%.  The former is set on W2K, XP,
+	   and later systems, the latter on Windows NT; Windows 9X
+	   doesn't set either.  */
+	if (userprofile && sys_access (userprofile, D_OK | W_OK) == 0)
+	  env_vars[i].def_value = strdup (userprofile);
+	else if (homedrive && homepath)
+	  {
+	    char homedir[MAX_PATH];
+
+	    strcat (strcpy (homedir, homedrive), homepath);
+	    if (sys_access (homedir, D_OK | W_OK) == 0)
+	      env_vars[i].def_value = strdup (homedir);
+	  }
+      }
+
+    /* Now handle the entire list of env_vars[].  */
     for (i = 0; i < (sizeof (env_vars) / sizeof (env_vars[0])); i++)
       {
 	if (!getenv (env_vars[i].name))

Re: $USERPROFILE for $HOME on W32

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Cc: monnier@iro.umontreal.ca, jasonr@gnu.org, emacs-devel@gnu.org
>> From: Andreas Schwab <schwab@suse.de>
>> Date: Sat, 27 Nov 2004 00:42:07 +0100
>> 
>> Any fixed length would be wrong, IMHO.  Can't this just be dynamically
>> allocated?
>
> Any _arbitrary_ fixed length is wrong.  But if the filesystem supports
> at most FILENAME_MAX-long file names, then using FILENAME_MAX for
> strings that hold file names is not arbitrary.

What if someone sets HOME to something longer?  It won't work as filename,
sure, but Emacs should not crash just because of this.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: $USERPROFILE for $HOME on W32

[Eli Zaretskii]

> Cc: jasonr@gnu.org, emacs-devel@gnu.org
> From: Andreas Schwab <schwab@suse.de>
> Date: Sat, 27 Nov 2004 14:26:36 +0100
> 
> What if someone sets HOME to something longer?  It won't work as filename,
> sure, but Emacs should not crash just because of this.

Right, so let's use strncpy to avoid the crash in that case.  Would
that be an okay solution?

Re: $USERPROFILE for $HOME on W32

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

> Right, so let's use strncpy to avoid the crash in that case.  Would
> that be an okay solution?

I'm ok with anything that doesn't result in buffer overflows.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: $USERPROFILE for $HOME on W32

[Lennart Borgman]

It seems to be hard to get a decision at the moment, but I hope it will be
cleared out. Could this please be put in FOR-RELEASE? Or, could Stephans
patch be tested? (I am unfortunately not the one to do this for several
reasons.)

- Lennart


----- Original Message ----- 
From: "Jason Rumney" <jasonr@gnu.org>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: <emacs-devel@gnu.org>
Sent: Monday, November 22, 2004 9:44 AM
Subject: Re: $USERPROFILE for $HOME on W32


> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > To follow up on the thread, here is a suggested patch.
> > Any objection?
>
> I'd rather put the code in init_environment() in w32.c, and keep all
> hacking of environment variables in one place.