By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,939 Members | 1,602 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,939 IT Pros & Developers. It's quick & easy.

Strange "feature" involving double slashes in Win98

P: n/a
Hello all.

I'm sending this to the list because I would like to know if someone
else has ever stumbled across this one, and also because one possible
solution is to patch, or simply "decorate", some of the Python
libraries functions (a few of the os and os.path calls). Note: if
you're going to reply, please read it *all* before doing so -- I've
already explored this problem quite a bit, and found no obvious
solution to it yet.

** The problem **

I am evaluating DrPython, one of the many IDEs available now. I had a
problem with it that I was able to track down to the particular way
the pathnames use by the program are constructed. To make a long story
short, Windows 98 doesn't like pathnames in the following format:

slashes: "c://somedir"
backslashes: r"c:\\somedir"

(it doesn't matter if the string is provided with forward or back
slashes. If the double slash is located immediately after the drive
letter+comma, then it bombs. The result can be a weird immediate
error, but in some cases one has to expect for a long timeout. Double
slashes of any sort are permitted in the middle of the pathname,
though)

The problem seems to have an obvious explanation. As probably everyone
knows, Windows uses a double slash notation for the machine name in
SMB shares. But wait -- the pathname includes a drive letter, so it
must not be a SMB share name! Or could it be? I never had seen before
a share named like this:

c:\\machinename\somedir

I really don't know if the pathname above is valid in SMB or not. But
I have good reason to believe that it should be invalid, as it makes
no sense (because of the drive letter, of course). Knowing that, the
problem can be reproduced in the DOS prompt quite easily:

a) cd c:\\windows --> fails with an "invalid folder" message
b) cd c:\\[my_workstation_name] --> abort, retry or ignore

Example (b) failed that way because I have disabled file serving in my
PC. But it's strange to note that it handled it differently just
because I used my own workstation name. I also don't know if this that
way problem affects other versions of Windows besides Win98SE. If you
try it, please let me know.

** Solving the problem **

DrPython relies on string concatenation to build new pathnames. My
root dir is "c:/", and at some places in the code, other pieces are
concatenated to it, causing the problem. In Unix it doesn't happen --
double slashes are fine anywhere. Knowing that, there are three
possible solutions for the problem:

1) Never write pathnames starting with double slashes.

It should be easy... but remember, I'm dealing with third party code
here. It will take some time for me to find out and correct all the
places where os functions are called with a pathname. I have tried to
do it, in fact, but still DrPython freezes from time to time due to
this problem as I find yet another place where a pathname is build
from the concationation of small pieces.

2) Fix os calls to correct the problem.

Not really sure about it... because I'm afraid that not this is not
going to ship with the standard Python library. After all, it's a
Windows bug.

3) Decorate os calls to correct the problem.

For now, that's my best bet for a generic solution that doesn't break
anyone else's code. I can write a wrapper for some of the affected OS
calls, and eliminate the double slashes out of the pathname before
calling the original function. It might work , but I still have to
test it.
Well, that's the problem. What's I'm supposed to do?

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com
Jul 18 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Carlos Ribeiro wrote:
** Solving the problem **

DrPython relies on string concatenation to build new pathnames. My
root dir is "c:/", and at some places in the code, other pieces are
concatenated to it, causing the problem.


It seems to me that the problem, here, is that DrPython *should* be
using os.path.join() to build those pathnames, instead of
concatenation. (os.path.join() intelligently removes duplicate
directory separators.) That may not help you much, though, since that's
not your code. (If you're not already reporting this as a [series of]
bug[s] in DrPython, you probably should...)

Given that fixing DrPython isn't a very practical option for you, I'd
say that wrapping the os module may be the best option left, but I'm not
sure how one would go about that. Given that os is a built-in module,
you'd probably have to pull some trickery with sys.modules once the
interpreter was started, and I don't understand that whole process well
enough to be able to offer specific advice.

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #2

P: n/a
>
Well, that's the problem. What's I'm supposed to do?


Maybe you can go for applying os.path.join and os.path.normpath to all
user-specified paths? I don't have windows, so I can't say how
os.path.normpath('c://foo') behaves, but maybe its does do the job.

--
Regards,

Diez B. Roggisch
Jul 18 '05 #3

P: n/a
Carlos Ribeiro wrote:
a) cd c:\\windows --> fails with an "invalid folder" message
b) cd c:\\[my_workstation_name] --> abort, retry or ignore


Additionally, as an extra data point, both of these failed with "The
system cannot find the path specified" on my Win2K machine, so it's not
just a Win9x issue. (I'm not sure if the fact that they're different
errors on your machine but the same error on my machine is significant,
but in either case it's still nonfunctional.)

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #4

P: n/a
Diez B. Roggisch wrote:
Well, that's the problem. What's I'm supposed to do?

Maybe you can go for applying os.path.join and os.path.normpath to all
user-specified paths? I don't have windows, so I can't say how
os.path.normpath('c://foo') behaves, but maybe its does do the job.


c:\>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
import os
os.path.normpath('c://somepath') 'c:\\\\somepath' os.path.abspath(os.path.normpath('c://somepath')) 'c:\\somepath' os.path.abspath('c://somepath')

'c:\\somepath'

Seems that normpath isn't up to the job, but abspath would be... if
it doesn't cause other problems. Since we're inherently dealing
with absolute paths for this problem, maybe it's adequate?

-Peter
Jul 18 '05 #5

P: n/a
On Tue, 14 Sep 2004 16:43:46 -0400, Peter Hansen <pe***@engcorp.com> wrote:
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on
win32
(...)
>>> os.path.abspath('c://somepath') 'c:\\somepath'


Strange. I've tried it here with different results.

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on win32
import os.path
os.path.abspath('c://work')

'c:\\\\work'

Of course, I'm not using the same build as you. Either there was some
bugfix inbetween 2.3.2 and 2.3.4, or the underlying libraries used by
ActivePython and standard Python differ in this regard (not highly
probable, anyway). I'm not sure.
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com
Jul 18 '05 #6

P: n/a
Carlos Ribeiro wrote:
On Tue, 14 Sep 2004 16:43:46 -0400, Peter Hansen <pe***@engcorp.com> wrote:
>>> os.path.abspath('c://somepath')

'c:\\somepath'


Strange. I've tried it here with different results.

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on win32
import os.path
os.path.abspath('c://work')


'c:\\\\work'

Of course, I'm not using the same build as you. Either there was some
bugfix inbetween 2.3.2 and 2.3.4, or the underlying libraries used by
ActivePython and standard Python differ in this regard (not highly
probable, anyway). I'm not sure.


Do you have pywin32 (win32all) installed? Try this one instead:

win32api.GetFullPathName('c://work')

This does the same as abspath does above, on mine. I ask because
of stuff in ntpath.py which appears to be calling the equivalent
of that instead of the normpath(join(getcwd(), path)) approach that
the docs note is equivalent...

-the-blind-leading-the-blind-ly y'rs,
Peter
Jul 18 '05 #7

P: n/a
On Tue, 14 Sep 2004 18:16:59 -0400, Peter Hansen <pe***@engcorp.com> wrote:
Do you have pywin32 (win32all) installed? Try this one instead:

win32api.GetFullPathName('c://work')

This does the same as abspath does above, on mine. I ask because
of stuff in ntpath.py which appears to be calling the equivalent
of that instead of the normpath(join(getcwd(), path)) approach that
the docs note is equivalent...


You're right. That's what I got now:

PythonWin 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32.
Portions Copyright 1994-2001 Mark Hammond (mh******@skippinet.com.au)
- see 'Help/About PythonWin' for further copyright information.
import win32api
win32api.GetFullPathName('c://work')

'c:\\\\work'

It seems that either ActivePython uses a different implementation for
os.abspath(), or the code changed between 2.3.2 and 2.3.4. The last
time I checked ActivePython was still using 2.3.2 -- I'll check it out
again, and upgrade if a newer version is available.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com
Jul 18 '05 #8

P: n/a
Carlos Ribeiro wrote:
On Tue, 14 Sep 2004 18:16:59 -0400, Peter Hansen <pe***@engcorp.com> wrote:
Do you have pywin32 (win32all) installed? Try this one instead:
win32api.GetFullPathName('c://work')

This does the same as abspath does above, on mine.


You're right. That's what I got now:

PythonWin 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32.
import win32api
win32api.GetFullPathName('c://work')


'c:\\\\work'

It seems that either ActivePython uses a different implementation for
os.abspath(), or the code changed between 2.3.2 and 2.3.4. The last
time I checked ActivePython was still using 2.3.2 -- I'll check it out
again, and upgrade if a newer version is available.


I reach a different conclusion. Note that when I said "this
does the same as abspath does above", I meant that *my* output
for the GetFullPathName() call is actually this:

'c:\\work'

In other words, it appears to be an OS difference. What flavour
and version of Windows are you running? I'm using XP Pro SP2.

-Peter
Jul 18 '05 #9

P: n/a
Oops. For some reason I misread your message. I'm using Win98 SE, and
have no plans to upgrade (at least while I'm limited to my current PC
setup).

Regarding this bug: if it's clear that this is Windows bug, does it
make sense to fix it in the libraries themselves? The bug exists, but
it doesn't affect much software because few people do things the
"wrong" way. A note in the documentation is more than enough to
clarify the actual workings of the code in the case of Win9x. I'll
report the bug to the DrPython guys, and let them solve the particular
issue with their software. I fixed the problem in a couple of
locations but I'm not sure if I found all relevant places.
On Tue, 14 Sep 2004 21:03:44 -0400, Peter Hansen <pe***@engcorp.com> wrote:
Carlos Ribeiro wrote:
On Tue, 14 Sep 2004 18:16:59 -0400, Peter Hansen <pe***@engcorp.com> wrote:
Do you have pywin32 (win32all) installed? Try this one instead:
win32api.GetFullPathName('c://work')

This does the same as abspath does above, on mine.


You're right. That's what I got now:

PythonWin 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32.
>import win32api
>win32api.GetFullPathName('c://work')


'c:\\\\work'

It seems that either ActivePython uses a different implementation for
os.abspath(), or the code changed between 2.3.2 and 2.3.4. The last
time I checked ActivePython was still using 2.3.2 -- I'll check it out
again, and upgrade if a newer version is available.


I reach a different conclusion. Note that when I said "this
does the same as abspath does above", I meant that *my* output
for the GetFullPathName() call is actually this:

'c:\\work'

In other words, it appears to be an OS difference. What flavour
and version of Windows are you running? I'm using XP Pro SP2.

-Peter
--
http://mail.python.org/mailman/listinfo/python-list


--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com
Jul 18 '05 #10

P: n/a
Carlos Ribeiro wrote:
Oops. For some reason I misread your message. I'm using Win98 SE, and
have no plans to upgrade (at least while I'm limited to my current PC
setup).

Regarding this bug: if it's clear that this is Windows bug, does it
make sense to fix it in the libraries themselves?


Not sure, but one could argue that if the OS routine to do this is
buggy, the code that was put in to take advantage of it should be
removed and a different approach taken. Or if it's important
enough, a special case could be inserted. I suspect your opinion
is valid on this: too few places have paths that look like c://work
to bother fixing this.

-Peter
Jul 18 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.