Skip to content

sys.executable generating canonical path #58296

Description

@alvesjnr
mannequin
BPO 14088
Nosy @pitrou, @vstinner, @ned-deily, @merwok, @akheron, @iritkatriel
Files
  • canonical_path.diff
  • sys_executable_realpath.patch
  • 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 2012-02-22.16:36:56.658>
    labels = ['type-bug', 'library', '3.9', '3.10', '3.11']
    title = 'sys.executable generating canonical path'
    updated_at = <Date 2021-08-31.21:58:44.018>
    user = 'https://bugs.python.org/alvesjnr'

    bugs.python.org fields:

    activity = <Date 2021-08-31.21:58:44.018>
    actor = 'vstinner'
    assignee = 'none'
    closed = False
    closed_date = None
    closer = None
    components = ['Library (Lib)']
    creation = <Date 2012-02-22.16:36:56.658>
    creator = 'alvesjnr'
    dependencies = []
    files = ['24604', '24607']
    hgrepos = []
    issue_num = 14088
    keywords = ['patch']
    message_count = 15.0
    messages = ['153970', '153993', '154008', '154009', '154010', '154012', '154015', '154019', '154108', '154448', '400435', '400618', '400619', '400651', '400787']
    nosy_count = 7.0
    nosy_names = ['pitrou', 'vstinner', 'ned.deily', 'eric.araujo', 'petri.lehtinen', 'alvesjnr', 'iritkatriel']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = None
    status = 'open'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue14088'
    versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']

    Activity

    1. alvesjnr commented on Feb 22, 2012

      alvesjnrmannequin
      MannequinAuthor

      Hi all,

      As it is my first time here, I'll try to explay step-by-step why I'm providing this path, and why I think that it is changing something that I believe that is not correct.

      First of all, I was trying to run one individual test, as the dev guide says:

      ./python -m test -v test_sys

      but, instead of run this test from the root directory of the project, I run it from ./Lib/test, so I did:

      ../../python -m test -v test_sys

      and it returned an error. The reason is that my sys.executable was not an abspath. When I went to see why it is different, I get this value to sys.executable:

      sys.executable -> '/home/antonio/Projects/cpython/Lib/test/../../python'

      I'm not sure if I'm thinking write, but for me don't look nice to have this value as sys.executable, once the real path should be:

      '/home/antonio/Projects/cpython/python'

      So I'm providing a paatch that do exactly this.

      Hope you enjoy

    2. pitrou commented on Feb 22, 2012

      @pitrou
      Member

      This is unfortunately wrong since it will fail in the face of symlinks.
      (if "foo" is a symlink to another directory, then "foo/../bar" is not the same thing as "bar")

    3. vstinner commented on Feb 22, 2012

      @vstinner
      Member

      We can use realpath() if the function is available. Something similar is already done for sys.argv[0]. We should also use GetFullPathNameW() on Windows.

    4. vstinner commented on Feb 22, 2012

      @vstinner
      Member

      See also the issue bpo-13402.

    5. pitrou commented on Feb 22, 2012

      @pitrou
      Member

      We can use realpath() if the function is available. Something similar
      is already done for sys.argv[0]. We should also use GetFullPathNameW()
      on Windows.

      GetFullPathName() is an abspath() equivalent. For realpath() you want
      GetFinalPathNameByHandle(), aka. _nt.getfinalpathname().

    6. vstinner commented on Feb 22, 2012

      @vstinner
      Member

      GetFullPathName() is an abspath() equivalent. For realpath() you
      want GetFinalPathNameByHandle(), aka. _nt.getfinalpathname().

      Ah? ntpath.realpath() uses nt._getfullpathname(). Is it a bug in ntpath?

    7. pitrou commented on Feb 22, 2012

      @pitrou
      Member

      Ah? ntpath.realpath() uses nt._getfullpathname(). Is it a bug in ntpath?

      Probably:

      # realpath is a no-op on systems without islink support
      realpath = abspath
    8. vstinner commented on Feb 22, 2012

      @vstinner
      Member

      > Is it a bug in ntpath?
      Probably

      Ok, I opened the issue bpo-14094.

    9. merwok commented on Feb 24, 2012

      @merwok
      Member

      I wonder if the doc for sys.executable should mention that .. segments may be present.

    10. akheron commented on Feb 27, 2012

      @akheron
      Member

      Éric Araujo wrote:

      I wonder if the doc for sys.executable should mention that ..
      segments may be present.

      Once this is fixed, it should say that .. segments may be present if
      there's realpath() is not available.

    11. iritkatriel commented on Aug 27, 2021

      @iritkatriel
      Member

      This is still unresolved:

      iritkatriel@Irits-MBP Lib % pwd
      /Users/iritkatriel/src/cpython-1/Lib
      iritkatriel@Irits-MBP Lib % ../python.exe -m test -v test_sys

      [snipped]

      ======================================================================
      FAIL: test_executable (test.test_sys.SysModuleTest)
      ----------------------------------------------------------------------

      Traceback (most recent call last):
        File "/Users/iritkatriel/src/cpython-1/Lib/test/test_sys.py", line 692, in test_executable
          self.assertEqual(os.path.abspath(sys.executable), sys.executable)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      AssertionError: '/Users/iritkatriel/src/cpython-1/python.exe' != '/Users/iritkatriel/src/cpython-1/Lib/../python.exe'
      - /Users/iritkatriel/src/cpython-1/python.exe
      + /Users/iritkatriel/src/cpython-1/Lib/../python.exe
      ?                                  +++++++
    12. added
      stdlibStandard Library Python modules in the Lib/ directory
      3.11only security fixes
      on Aug 27, 2021
    13. vstinner commented on Aug 30, 2021

      @vstinner
      Member

      test_sys:

          def test_executable(self):
              # sys.executable should be absolute
              self.assertEqual(os.path.abspath(sys.executable), sys.executable)

      IMO the test is wrong. It must test: test.assertTrue(os.path.isabs(sys.executable)).

      The path is not required to be normalized.

    14. vstinner commented on Aug 30, 2021

      @vstinner
      Member

      The path is not required to be normalized.

      I'm talking about the current implementation.

      I'm not against making Python even better: attempt to normalize the path ;-)

    15. ned-deily commented on Aug 30, 2021

      @ned-deily
      Member

      I'm not against making Python even better: attempt to normalize the path ;-)

      I would be very cautious about doing that. I'm pretty sure it would break some existing code.

    16. vstinner commented on Aug 31, 2021

      @vstinner
      Member

      See also bpo-20443 "__code__. co_filename should always be an absolute path". I had a revert a change which affected sys.argv[0]:

      commit a1a99b4
      Author: Victor Stinner <vstinner@python.org>
      Date: Mon Dec 9 17:34:02 2019 +0100

      bpo-20443: No longer make sys.argv[0] absolute for script (GH-17534)
      
      In Python 3.9.0a1, sys.argv[0] was made an asolute path if a filename
      was specified on the command line. Revert this change, since most
      users expect sys.argv to be unmodified.
      
    17. transferred this issue fromon Apr 10, 2022
    18. added
      pendingThe issue will be closed if no feedback is provided
      and removed
      3.11only security fixes
      on Aug 10, 2026
    19. devdanzin commented on Aug 10, 2026

      @devdanzin
      Member

      Given the probability of breaking user code, setting as pending. Please revert if this is deemed desirable.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      pendingThe issue will be closed if no feedback is providedstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions