> On 25/05/2006 8:12 PM, Metz, Bobby W, WWCS wrote:
> > Mark,
> > Thanks for that. I didn't read an earlier entry from the
> > submitter close enough. Someone else had told them that
> > GetShortPathName wasn't supported but I didn't pay attention to the W at
> > the end...could have saved myself a couple of posts if I had. I'll
> > chalk my "lack of clear direction" up to this as well...I was excluding
> > GetShortPathName in my search due to comment below.
> >
> >>> Looks like you need a GetShortPathNameW() but it's not
> > implemented.
> >>> Raise it as an issue on the pywin32 sourceforge bug register.
> >>> Tell Mark
> >>> I sent you :-)
> >
>
> Oh boy am I glad that's been sorted out. It was in danger of becoming
> "Hysterically Confused Thread of the Month" :-)
Hi John!
I'm surprised you didn't chastise me until I produced a better example
that fully demonstrates the obscure corners in this area <wink>. For
example, the open() builtin (plus many other related functions) natively
support Unicode strings and calls the unicode versions of the underlying
Microsoft C runtime functions. The following demonstrates this, and doesn't
rely on an already existing file:
>>> open(u"c:\\temp\\\xa9opyright someone.txt", "w").write('hello there!')
>>> win32api.GetShortPathName(u"c:\\temp\\\xa9opyright
someone.txt".encode("mbcs"))
'c:\\temp\\OPYRIG~1.TXT'
>>> open('c:\\temp\\OPYRIG~1.TXT').read()
'hello there!'
>>>
In this example, pywin32 is the 'weak-link' in the Unicode story - and that
doesn't sound like something we can let stand - so I just checked in a
change that if win32api.GetShortPathName() is passed unicode, it calls
GetShortPathNameW and returns a unicode object. So in the next build, you
will see:
>>> win32api.GetShortPathName(u"c:\\temp\\\xa9opyright someone.txt")
u'c:\\temp\\OPYRIG~1.TXT'
Cheers,
Mark
_______________________________________________
Python-win32 mailing list
Python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
