Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[doc] os.execvp[e] on win32 fails for current directory #44123

Closed
snaury mannequin opened this issue Oct 13, 2006 · 12 comments
Closed

[doc] os.execvp[e] on win32 fails for current directory #44123

snaury mannequin opened this issue Oct 13, 2006 · 12 comments
Labels
3.8 (EOL) end of life 3.9 only security fixes 3.10 only security fixes docs Documentation in the Doc dir type-bug An unexpected behavior, bug, or error

Comments

@snaury
Copy link
Mannequin

snaury mannequin commented Oct 13, 2006

BPO 1576313
Nosy @loewis, @bitdancer
Files
  • python-win32-execvp.patch
  • Issue1576313.diff: Add one sentence to os.rst
  • 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 = None
    created_at = <Date 2006-10-13.00:57:39.000>
    labels = ['type-bug', '3.8', '3.9', '3.10', 'docs']
    title = '[doc] os.execvp[e] on win32 fails for current directory'
    updated_at = <Date 2020-11-06.19:58:06.206>
    user = 'https://bugs.python.org/snaury'

    bugs.python.org fields:

    activity = <Date 2020-11-06.19:58:06.206>
    actor = 'iritkatriel'
    assignee = 'docs@python'
    closed = False
    closed_date = None
    closer = None
    components = ['Documentation']
    creation = <Date 2006-10-13.00:57:39.000>
    creator = 'snaury'
    dependencies = []
    files = ['7576', '35690']
    hgrepos = []
    issue_num = 1576313
    keywords = ['patch']
    message_count = 11.0
    messages = ['51239', '51240', '51241', '51242', '51243', '51244', '109177', '109184', '220948', '220952', '220980']
    nosy_count = 6.0
    nosy_names = ['loewis', 'snaury', 'techtonik', 'mcmahon_m', 'r.david.murray', 'docs@python']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = 'needs patch'
    status = 'open'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue1576313'
    versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

    Linked PRs

    @snaury
    Copy link
    Mannequin Author

    snaury mannequin commented Oct 13, 2006

    By convention when program is executed by searching
    path, the first directory to be searched should be the
    current directory. However on python this is not true:

    1.c:
      int main() { return 1; }

    test.py:
    import os
    os.execvp('1', ('1',))

    result:
      Traceback (most recent call last):
        File "C:\1\test.py", line 2, in <module>
          os.execvp('1',('1',))
        File "D:\Programs\ActiveState\Python25\lib\os.py",
    line 348, in execvp
          _execvpe(file, args)
        File "D:\Programs\ActiveState\Python25\lib\os.py",
    line 386, in _execvpe
          func(fullname, *argrest)
      OSError: [Errno 2] No such file or directory

    Attached patch fixes this.

    @snaury snaury mannequin added OS-windows labels Oct 13, 2006
    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Oct 14, 2006

    Logged In: YES
    user_id=21627

    What convention are you referring to? By convention, you
    have to specify executables in the current directory with
    ./<program> if you don't have "." in your path.

    @snaury
    Copy link
    Mannequin Author

    snaury mannequin commented Oct 14, 2006

    Logged In: YES
    user_id=1197042

    On win32 it is not so, execlp() in msvcrt, for example, will
    always looks in current directory before looking on PATH
    (and if I remember correctly OS/2 has the same rules, I
    don't remember PATH on OS/2 ever needing . in the PATH), so
    does CreateFile, so on win32 it's just what is expected.
    Sorry if I'm wrong though...

    @mcmahonm
    Copy link
    Mannequin

    mcmahonm mannequin commented Mar 7, 2007

    I don't know about OS/2 but standard windows definitely looks in the current folder first.

    Should the patch insert "." rather then ""?

    >>> import os.path
    >>> os.path.join("", "test")
    'test'
    >>> os.path.join(".", "test")
    '.\\test'
    >>>

    @snaury
    Copy link
    Mannequin Author

    snaury mannequin commented Mar 7, 2007

    No, inserting '.' is unnecessary exactly because ntpath.join is working the way you described. On Windows and OS/2 'test' will mean 'test' in current directory, i.e. the expected result without any unnecessary characters prepended and without any unnecessary cycles since ntpath.join("", "whatever") is optimized in ntpath.join.

    @mcmahonm
    Copy link
    Mannequin

    mcmahonm mannequin commented Mar 7, 2007

    Yes of course! I had slightly misunderstood the original problem. I had thought it was execv/execve that had to have the full path, but I see that it is actually os._execvpe() that is only looking in explicit path entry locations for the file (and we need to add the implicit by allowing file to be found).

    @devdanzin devdanzin mannequin added type-feature A feature request or enhancement labels Mar 30, 2009
    @techtonik
    Copy link
    Mannequin

    techtonik mannequin commented Jul 3, 2010

    There should be one uniform behavior on all platforms if Python is crossplatoform.

    As far as I can understand this issue - unix os.execv() requires "./" to be present to execute anything from current directory. On windows it is enough to specify just filename, but os.execv() doesn't work in this way - is that right and the issue is to make behavior of os.execv() like on windows?

    The current behavior definitely needs to be documented.

    @bitdancer
    Copy link
    Member

    The unix model should be followed (requiring an explicit reference to the current directory if it is not already in PATH), rather than the insecure Windows behavior, and this is indeed the current situation. The current behavior is documented ("a full or relative path"), but a footnote that this differs from the msvcrt behavior would probably be a useful addition. So I'm changing this to a doc bug. (I have verified that ./ works, I have not verified the msvcrt behavior.)

    @bitdancer bitdancer added docs Documentation in the Doc dir and removed OS-windows labels Jul 3, 2010
    @bitdancer bitdancer added type-bug An unexpected behavior, bug, or error docs Documentation in the Doc dir and removed type-feature A feature request or enhancement OS-windows labels Jul 3, 2010
    @bitdancer bitdancer added type-bug An unexpected behavior, bug, or error and removed type-feature A feature request or enhancement labels Jul 3, 2010
    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Jun 18, 2014

    I'd intended to write a patch but got confused as msg51241 talks about "execlp() in msvcrt" but execlp is in the os module. Please advise.

    @bitdancer
    Copy link
    Member

    os.execlp *wraps* the interface of the same name in the platform C library. On Windows, that is execlp in the msvcrt[*]. On Linux, it is usually the execlp in glibc.

    [*] 'crt' stands for 'C runtime'.

    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Jun 19, 2014

    The patch deliberately says Windows msvcrt to distinguish it from the Python module of the same name.

    @iritkatriel iritkatriel added 3.8 (EOL) end of life 3.9 only security fixes 3.10 only security fixes labels Nov 6, 2020
    @iritkatriel iritkatriel changed the title os.execvp[e] on win32 fails for current directory [doc] os.execvp[e] on win32 fails for current directory Nov 6, 2020
    @iritkatriel iritkatriel added the 3.8 (EOL) end of life label Nov 6, 2020
    @iritkatriel iritkatriel added 3.9 only security fixes 3.10 only security fixes labels Nov 6, 2020
    @iritkatriel iritkatriel changed the title os.execvp[e] on win32 fails for current directory [doc] os.execvp[e] on win32 fails for current directory Nov 6, 2020
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    zooba added a commit that referenced this issue Apr 24, 2023
    @hugovk
    Copy link
    Member

    hugovk commented Nov 10, 2023

    So I'm changing this to a doc bug

    Closing this issue, #93826 has been merged that updated the docs.

    @hugovk hugovk closed this as completed Nov 10, 2023
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.8 (EOL) end of life 3.9 only security fixes 3.10 only security fixes docs Documentation in the Doc dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants