Maor Kleinberger <kma...@gmail.com> added the comment:
> Ah, I think I follow now. But I'm not sure what you mean by wanting it to
> "retain an initial '.' component" - how would you expect that to work in
> practice? p1.parts == ('.', 'c:a')? I suspect that could break existing code.
I've dealt with that in my PR by checking in the __str__ method if the path
could be misinterpreted, and if so prepending a './'.
> > The CreateProcessW case is a generalization of the case that we're used to
> > across various platforms, in which, for the sake of security, the "." entry
> > is excluded from PATH. In this case, the only way to run an executable in
> > the working directory is to reference it explicitly. For example (in Linux):
[...]
> > This would work if pathlib kept the initial "." component.
> Thanks, this is a really useful example, as it makes it clear that this is a
> general issue, not a platform-specific quirk.
In my opinion, this is a different problem, that its solution doesn't
necessarily belong in pathlib. Pathlib is responsible to parse, manipulate and
display paths correctly (which it fails to do with the case of Path('./a:b') ->
Path('a:b')). 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.
> Having said all of this, I'm not at all sure how much it relates to the
> original description of this issue, which didn't mention initial './'
> components at all. Is the originally reported behaviour a *consequence* of
> not retaining './', or is it a separate problem? If the latter, then maybe
> "Pathlib should retain an initial './'" would be better raised as a separate
> bpo item (and PR)?
I completely agree that any change made to support retaining the initial './'
for process invocation should be made in a different bpo item and PR. I do
disagree though, that such change should be made, as like I wrote above, this
is only needed for CreateProcessW's interface, and isn't related to pathlib's
logic itself.
Maybe, a nice idea would be to open a separate PR that would add a utility for
dealing with executing paths. Something like Path.popen(cmd_args, **kwargs),
that will call Popen with a path prepended with a './' if needed.
----------
_______________________________________
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
