Eryk Sun <eryk...@gmail.com> added the comment:
> set "HOME" to override a location derived from ~
Using HOME in Windows is not reliable because it is not a system environment
variable. That makes it fair game for administrators, users, and applications
to use however they like.
Platform differences can be papered over with functions. For example, add
set_user_home(dir) and get_user_home(name=''). set_user_home sets a private
global variable named _user_home, which defaults to None. get_user_home returns
_user_home if it's not None and name is an empty string. Otherwise it gets the
home directory per platform rules.
> If on Windows and Python 3.8 or later, set USERPROFILE to the
> target directory.
This is unfortunate. Modifying USERPROFILE is highly unusual. USERPROFILE is
the location of the user's "NTUSER.DAT" registry hive and local application
data ("AppData\Local"), including "UsrClass.dat" (the "Software\Classes"
registry hive). It's also the default location for a user's known shell folders
and home directory. Modifying USERPROFILE shouldn't cause problems with any of
this, but I'm not completely at ease with it.
If a user profile defines a custom home directory (e.g. net user <username>
/homedir:<dir>), it will be reflected in "%HOMEDRIVE%%HOMEPATH%", and not in
USERPROFILE. In a more perfect world, in which no one ever depended on the
default location of shell folders, I'd recommend flipping the order around in
ntpath.expanduser to prefer "%HOMEDRIVE%%HOMEPATH%".
That said, a major snag with HOMEDRIVE and HOMEPATH is that they're sometimes
wrong or missing. CreateEnvironmentBlock() will enumerate but won't populate
the user's "Volatile Environment" registry key, which is where HOMEDRIVE and
HOMEPATH are normally set. This key gets populated during startup of a desktop
session, and, since it's volatile, it gets deleted when the profile is unloaded
(i.e. the user logs off). Consequently the Secondary Logon service (i.e.
CreateProcessWithLogonW), which runas.exe uses, will only set the correct
HOMEDRIVE and HOMEPATH values if the user is already logged on as a desktop
session user. Otherwise it uses a default value of "%SystemRoot%\System32" as
the home directory, which is spectacularly wrong. Similarly, a scheduled task
that uses an S4U batch logon won't even have HOMEDRIVE and HOMEPATH defined if
the task user isn't already logged on as a desktop session user. USERPROFILE
will still be correct in these cases.
> Windows is posix-compliant. What you probably mean here is "Unix".
The Windows subsystem has never been POSIX compliant. At most, Microsoft's C
runtime library provides rudimentary POSIX API support (e.g. open, read).
On the other hand, NT's original POSIX subsystem (psxss.exe) was POSIX.1 (1990)
compliant. In 1999, Microsoft purchased the more capable OpenNT Unix system
from Softway Systems and rebranded it as Interix. In Server 2003 R2, Interix
was integrated in NT as the Subsystem for UNIX-based Applications (SUA). It was
removed in Server 2012 R2. Microsoft abandoned the old conception of an NT
subsystem in favor of virtualization concepts such as pico processes and pico
providers (WSL 1) or hosting a kernel in a light-weight VM (WSL 2).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
