[ python-Bugs-665336 ] win32 os.path.normpath not correct for leading slash cases

[SourceForge.net]

Bugs item #665336, was opened at 2003-01-09 22:42
Message generated for change (Comment added) made by gergan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665336&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan R.A. Deibel (sdeibel)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32 os.path.normpath not correct for leading slash cases

Initial Comment:
os.path.normpath on win32 misses two cases in its
duplicate slash
removal code that I believe should be dealt with:

c:\x\y\z
\\x\y\z

Both of these are returned unchanged.

I've attached an implementation that fixes these to
return the following, respectively:

c:\x\y\z
\x\y\z

I did see the other normpath bugs that were reported
and rejected
and think that the above isn't also a case of "garbage
in garbage out" but of course there's room for
interpretation.

I am a bit unsure about the UNC case since Posix
collapses only 3+ leading slashes to a single slash and
otherwise leaves up to two slashes.  But in the context
of win32 the above seems to make more sense to me.

Thanks,

Stephan Deibel
Wing IDE Developer
Archaeopteryx Software

--------------------

def normpath(path):
    """Normalize path, eliminating double slashes, etc."""
    path = path.replace("/", "\")
    prefix, path = os.path.splitdrive(path)
    if prefix == '':
        max_leading = 2
    else:
        max_leading = 1
    i = 0
    while path[:1] == "\":
        if i < max_leading:
            prefix = prefix + "\"
            i += 1
        path = path[1:]
    comps = path.split("\")
    i = 0
    while i < len(comps):
        if comps[i] in ('.', ''):
            del comps[i]
        elif comps[i] == '..':
            if i > 0 and comps[i-1] != '..':
                del comps[i-1:i+1]
                i -= 1
            elif i == 0 and prefix.endswith("\"):
                del comps[i]
            else:
                i += 1
        else:
            i += 1
    # If the path is now empty, substitute '.'
    if not prefix and not comps:
        comps.append('.')
    return prefix + "\".join(comps)


----------------------------------------------------------------------

Comment By: gergan (gergan)
Date: 2005-07-19 18:59

Message:
Logged In: YES 
user_id=1301159

nevermind, it actually is not a bug as the comment says it all 
# POSIX allows one or two initial slashes, but treats three
or more
# as single slash.
I didn't know this. Excuse me and forget my posting ::))


----------------------------------------------------------------------

Comment By: gergan (gergan)
Date: 2005-07-19 18:50

Message:
Logged In: YES 
user_id=1301159

I'm experiencing the same bug on linux with
Python 2.4.1 (#1, Jun 28 2005, 21:03:32) 
[GCC 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)]
all the paths beginning with double slash are left unchanged
from os.path.normpath.
so expected behaviour would be (as stated in the documentation)
>>>os.path.normpath ("//usr/lib")
'/usr/lib'
the actual result is:
>>>os.path.normpath ("//usr/lib")
'//usr/lib'


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-19 21:25

Message:
Logged In: YES 
user_id=752496

I've the following behaviour in 2.4b1:

>>> os.path.normpath(r"\x\y\z")
'\x\y\z'
>>> os.path.normpath(r"\x\y\z")
'\x\y\z'
>>> os.path.normpath(r"\x\y\z")
'\x\y\z'

which is ok to me, and

>>> os.path.normpath(r"\x\y\z")
'\\x\y\z'

which seems bad.

I'm setting this bug to the 2.4 group.


----------------------------------------------------------------------

Comment By: Stephan R.A. Deibel (sdeibel)
Date: 2004-11-17 05:04

Message:
Logged In: YES 
user_id=12608

Good god, notification email is munging the number of
backslashes inconsistently depending on quoting -- see the
sf bug entry in a browser to see the right thing.  Sorry
about that!

----------------------------------------------------------------------

Comment By: Stephan R.A. Deibel (sdeibel)
Date: 2004-11-17 05:00

Message:
Logged In: YES 
user_id=12608

The c:\x\y\z case was broken up to 2.3.4 but appears fixed
in 2.4b2, as you noticed (it used to return "c:\\x\y\z"
and now returns "c:\x\y\z" as it
should).

However in 2.4b4 the \x\y\z case still returns
"\\x\y\z" (it
returns any number of leading backslashes unchanged, no
matter how 
many are passed in):

>>> os.path.normpath(r"\x\y\z")
'\\x\y\z'
>>> os.path.normpath(r"\\x\y\z")
'\\\x\y\z'

I'm still fairly sure it should return "\x\y\z" instead
as the more appropriate 
normalization of this kind of path on win32.

Hope that helps!  Thanks for your work on clearing the bug list!


----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-17 00:17

Message:
Logged In: YES 
user_id=752496

Don't understand what you're proposing: in Py2.4b2 (Win2K
SP4) I got:

>>> os.path.normpath("c:\x\y\z")
'c:\x\y\z'

and that seems ok to me.

.    Facundo

----------------------------------------------------------------------

Comment By: Facundo Batista (facundobatista)
Date: 2004-11-17 00:17

Message:
Logged In: YES 
user_id=752496

Please, could you verify if this problem persists in Python 2.3.4
or 2.4?

If yes, in which version? Can you provide a test case?

If the problem is solved, from which version?

Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".

Thank you! 

.    Facundo

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665336&group_id=5470