Eryk Sun <eryk...@gmail.com> added the comment:
> In contrast, in the case of CreateProcessW, both Path('./exec') and
> Path('exec') are the *correct* paths to the executable. The ./ is not
> necessary in that case to display the path correctly, but just to
> interact correctly with CreateProcessW's interface.
It's semantic information, just for different reasons than the "./c:a" case. In
this case, it's about what a path means in a search context. I think specifying
a filesystem path for a search disposition is as valid a use case as is
specifying a path for an open or create disposition.
In Windows, the qualified path r".\exec" is resolved relative to just the
working directory. Classically, for an unqualified name such as "exec", the
working directory is checked after the application directory. Starting with
Windows Vista, CreateProcessW and the CMD shell won't check the working
directory at all for unqualified "exec" if NoDefaultCurrentDirectoryInExePath
is set in the environment, not unless a "." entry is explicitly added to PATH.
The behavior of CreateProcessW also differs for r".\spam\exec" vs r"spam\exec".
Without explicitly including the leading ".", the system searches every
directory in the executable search path (i.e. the application directory,
working directory, system directories, and PATH). This differs from Unix, in
which any path with a slash in it is always resolved relative to the working
directory. Getting this behavior in Windows requires using the qualified path
r".\spam\exec".
We may want either behavior. I think if a path is specified explicitly with a
leading "." component, or joined from one, the "." component should be
preserved, just as we already preserve a leading ".." component.
This is a separate issue, as I suggested in the PR comment. It was just
supposed to be a related issue that you might be interested in. I didn't intend
to conflate it with this issue.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
