> From: Bruno Haible <br...@clisp.org>
> Cc: Eli Zaretskii <e...@gnu.org>
> Date: Tue, 30 Mar 2021 02:50:53 +0200
>
> > +#else /* WINDOWS32 */
> > + /* We don't support ~USER on MS-Windows (FIXME: could have
> > + at least supported that if USER == $USERNAME). */
> > + if (flags & GLOB_TILDE_CHECK)
> > + {
> > + retval = GLOB_NOMATCH;
> > + goto out;
> > + }
> > +#endif /* WINDOWS32 */
> > }
> > }
> >
>
> Your patch is consistent with the behaviour of this code on Unix,
> when the user does not exist.
Yes, but the current code already behaves like that, it just doesn't
say so. My suggestion is a minor improvement, not a significant one:
it just makes 'glob' behave according to GLOB_TILDE_CHECK instead of
ignoring it. (I found this issue by running the GDB self-test, which
specifically tests this aspect of tilde expansion.)
> But would it not be possible to support the ~user syntax also on
> Windows? By creating a gnulib module 'getpwnam' based on the
> function GetUserProfileDirectory() [1][2] ?
AFAIK, GetUserProfileDirectory for another user requires that you know
that user's credentials. For example, one of the links you sent talks
about LogonUser, which will ask for that user's password. The MS docs
of LogonUser says:
The LogonUser function attempts to log a user on to the local
computer. The local computer is the computer from which LogonUser
was called. You cannot use LogonUser to log on to a remote
computer. You specify the user with a user name and domain and
authenticate the user with a plaintext password. If the function
succeeds, you receive a handle to a token that represents the
logged-on user. You can then use this token handle to impersonate
the specified user or, in most cases, to create a process that runs
in the context of the specified user.
I don't think it's reasonable for a library to ask for a password, and
for any non-trivial user account the chances of the current user to be
able to type the password are probably nil. (The example on
StackOverflow uses "guest", which may mean this account has no
password.)
It _is_ possible to get the information using the NetUserGetInfo API.
However, for a local computer that API always returns an empty string
for the user's home directory (as AFAIU local accounts don't record
this information, only domain servers do). And in any case, this and
other similar APIs cannot return the accurate results if the other
user defines HOME to point to somewhere else; access to environment
variables of another user again requires that user's credentials.
So I think trying to make a fully-functional getpwnam on Windows is
more trouble than it's worth, and in all practical applications I've
seen (including Emacs, for example), supporting ~USER for the current
user is more than enough.
