Re: [PATCH] for review - Allow expansion of "~" (as opposed to "~user")

[Eli Zaretskii]

> From: Michal Nazarewicz <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Mon, 02 Mar 2015 21:37:56 +0100
> 
> >> Looking at that code, it appears it’s inconsistent on Windows when it
> >> comes to handling ~/.emacs.d/init.el.  If I understand it correctly,
> >> here’s how Emacs behave on Windows:
> >> 
> >> * emacs        -> load ~/.emacs, ~/_emacs or ~/.emacs.d/init.el
> >> * emacs -u foo -> load ~/.emacs or ~/_emacs
> >
> > I'm not bothered about the inconsistency, since the "-u foo"
> > "handling" is a kludge for a situation that shouldn't happen.  I
> > wouldn't object to emitting an error in that case.
> 
> Doesn’t this basically mean doing this:
> 
> -       (if (file-directory-p (expand-file-name
> -                              ;; We don't support ~USER on MS-Windows
> -                              ;; and MS-DOS except for the current
> -                              ;; user, and always load .emacs from
> -                              ;; the current user's home directory
> -                              ;; (see below).  So always check "~",
> -                              ;; even if invoked with "-u USER", or
> -                              ;; if $USER or $LOGNAME are set to
> -                              ;; something different.
> -                              (if (memq system-type '(windows-nt ms-dos))
> -                                  "~"
> -                                (concat "~" init-file-user))))
> -           nil
> -         (display-warning 'initialization
> +       (unless (file-directory-p (expand-file-name
> +                                   (concat "~" init-file-user)))
> +          (display-warning 'initialization
> 
> and then using ~user/… for every system including windows-nt?

Not exactly.  First, we had what you suggest before 1df1e49eb, so
going back to that code means re-introducing the problem it solved.

Second, it's not really nice to have init-file-user have the value of,
say, "~bob/.emacs", when Emacs was invoked with "-u bob", whereas in
fact we loaded "C:/fred's-home/.emacs".  It's a lie, and one that's
tricky to untangle: you need to know that to get a _real_ file name,
you need to run it through expand-file-name.  If you don't, things
will subtly fail, e.g., if you compare this with some other file name.

So I'd rather we either errored out with such invocation, or fixed the
value to not lie, as we do now.

> If I understand correctly, ~user/… expansion depends on getpwnam and a)
> on MS-DOS DJGPP provides it (by having a single pw entry for user ==
> current user), b) on W32 src/w32.c provides it (with the same
> implementation) and on POSIX we have it properly implemented.

Approximately true, but not entirely.  w32.c's emulation of getpwnam
only recognizes the actual name of the current user of the Windows
session, while the DJGPP version allows to "customize" the user by
setting environment variables.  So "-u USER" on Windows will only work
if USER is identical to the current user, while on DOS we can have
other "users" by tweaking the environment.

Another important piece of the puzzle is that if USER is not
recognized as a valid user by the getpwnam emulation on
MS-Windows/MS-DOS, you get this:

  (expand-file-name "~USER") => /current/directory/~USER

And it is possible to have a literal "~USER" directory, in which case
the warning will be incorrectly skipped.