Suggested change in how ntpath.expanduser works

[timehorse]

BPO	802159
Nosy	@loewis
Files	ntpath.py: ntpath.py with proposed changes

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2004-08-18.12:48:19.000>
created_at = <Date 2003-09-07.22:08:10.000>
labels = ['OS-windows']
title = 'Suggested change in how ntpath.expanduser works'
updated_at = <Date 2004-08-18.12:48:19.000>
user = 'https://bugs.python.org/timehorse'

bugs.python.org fields:

activity = <Date 2004-08-18.12:48:19.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Windows']
creation = <Date 2003-09-07.22:08:10.000>
creator = 'timehorse'
dependencies = []
files = ['5570']
hgrepos = []
issue_num = 802159
keywords = ['patch']
message_count = 3.0
messages = ['44581', '44582', '44583']
nosy_count = 2.0
nosy_names = ['loewis', 'timehorse']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue802159'
versions = []

[timehorse]

There exists a problem in the MS Knowledge base
(http://support.microsoft.com/?kbid=236813) which
documents some issues with using the %HOMEDRIVE%
and %HOMEPATH% to generate a home directory.
(Note, in XP systems these variables seeom to set
correctly, though this problem exists in Win2k and likely
WinNT.) Given this and that in non-network situations
these variables are not preferred I propose the changes
explained in the following note:

Windows may be run over a network (Distributed File
System or DFS) or as a stand-alone [multi-user] box. In
order to determine a tilde-expanded network path in a
DFS environment, one must use the concatenation of %
HOMEDRIVE% and %HOMEPATH%. In the stand-alone
case, home directories are not part of a DFS path
expansion. On these machines, %HOMEDRIVE% and %
HOMEPATH% may default to "C:" [%SYSTEMDRIVE% ??]
and "\", respectively. While a %HOMEPATH% of "\" is
quite common under DFS as well, if the "network" path
is "C:" [or %SYSTEMDRIVE%], this is a stand-alone
system and stand-alone rules should apply by default. If
however the %USERPROFILE% variable does not exist,
the DFS interpretation will default and you still end up
with "C:\" as your result.

The upshot of a stand-alone system is that other users
can be tilde-expanded based on the variable %
ALLUSERSPROFILE%/../<name>, where name is the name
given in the tilde. However, since Windows allows
whitespace names, the tilde must either be 8.3
contracted or the fully-qualified user name. This
function will not verify if the name exits -- that is left to
the caller's use of the result. We require %
ALLUSERSPROFILE% rather than just manipulating %
USERPROFILE% to assure this is a multi-user system.

Finally, the local_path variable indicates whether
the "My Documents" element should be appended. On
Win9x boxes which don't have a DFS path or %
USERPROFILE%, this translates typically to "C:\My
Documents". For NT, Win2k and XP, this typically
means "%USERPROFILE%/My Documents". This is
because the profile is not a good directory to edit files
in -- it is the equivalent to writing to a hidden system
directory under UNIX.

Note however that we still prefer %HOME% because it
was almost certainly manually set and this is not "My
Documents" expanded.

A similar implementation can be provided in the
dospath.expanduser method though here the "My
Documents" expansion should only be used on Win9x
machines, not true DOS systems. Since the ntpath
library SHOULD be imported on these Win9x systems
(AFAICT from the Documentation) no change would
therefore be necessary in dospath to support this.

[timehorse]

Logged In: YES
user_id=836867

I forgot to mention this solution unfortunately would only
work on English windows systems, as international Windows
use the literal translation of "My Documents", e.g. "Mes
Documents" for the official user folder. I will look into how I
might fix this problem in the generic case (perhaps by
scanning the registry) but would also like to add perhaps
given that Mac OS X has gone in this direction that there be
a generic get_my_documents([user]), get_my_pictures
([user]) and get_my_desktop([user]) supported as stubs in
those systems that don't support it and return the relavent
directory for nt and OSX.

[loewis]

Logged In: YES
user_id=21627

It appears that no update to this patch has been received -
considering it withdrawn.