How to get the filename in the right case ?

[Stef Mientki]

hello,

How can I find the correct case of a filename ?

Background in my program I use case sensitive filenames, just like
Python requires.
Now I've integrated pdb into the program,
but pdb acts somwhat strange:
upon a breakpoint it gives the filename always in lowercase (probably
this only happens on windows).

So is there a way to get the correct case of a given filename in lowercase ?

One solution might be to make the comparison in my program always with
lowercase,
but then I'm sure the program won't work on non-windows systems.

btw, why does pdb behave that way ( Python 2.5 ) ?

thanks,
Stef Mientki

[Diez B. Roggisch]

Stef Mientki wrote:

hello,

How can I find the correct case of a filename ?

Background in my program I use case sensitive filenames, just like
Python requires.
Now I've integrated pdb into the program,
but pdb acts somwhat strange:
upon a breakpoint it gives the filename always in lowercase (probably
this only happens on windows).

So is there a way to get the correct case of a given filename in lowercase
?

One solution might be to make the comparison in my program always with
lowercase,
but then I'm sure the program won't work on non-windows systems.

btw, why does pdb behave that way ( Python 2.5 ) ?

I doubt it does. It sure doesn't on unix, and I fail to see any reason why
it should do that on windows - given that the total number of lower() in
pdb.py amounts to one, and that's used to process user-input such
as "Yes", "y", "YES" or whatnot.

Are you sure you are not processing the content through some lower()-call
when embedding pdb?

Diez

[Stef Mientki]

Diez B. Roggisch wrote:

Stef Mientki wrote:

>hello,

How can I find the correct case of a filename ?

Background in my program I use case sensitive filenames, just like
Python requires.
Now I've integrated pdb into the program,
but pdb acts somwhat strange:
upon a breakpoint it gives the filename always in lowercase (probably
this only happens on windows).

So is there a way to get the correct case of a given filename in lowercase
?

One solution might be to make the comparison in my program always with
lowercase,
but then I'm sure the program won't work on non-windows systems.

btw, why does pdb behave that way ( Python 2.5 ) ?

I doubt it does. It sure doesn't on unix, and I fail to see any reason why
it should do that on windows - given that the total number of lower() in
pdb.py amounts to one, and that's used to process user-input such
as "Yes", "y", "YES" or whatnot.

Yes I'm pretty sure, two reasons:
1. when I perform a step_into, jumping into a file that doesn't have
breakpoints itself (meaning my program doesn't even know of this file),
pdb returns a lowercase filename
2. rpdb2 (probably based or even inherited from pdb) has the same
behavior. Asking the writer of rpdb2, I got some excuse (which I didn't
understand) why he had done it that way.

Are you sure you are not processing the content through some lower()-call
when embedding pdb?

But maybe pdb does ?

thanks anyway,
Stef

>
Diez
--
http://mail.python.org/mailman/listinfo/python-list

[Diez B. Roggisch]

Yes I'm pretty sure, two reasons:

1. when I perform a step_into, jumping into a file that doesn't have
breakpoints itself (meaning my program doesn't even know of this file),
pdb returns a lowercase filename

What has that to do with potential output postprocessing?

2. rpdb2 (probably based or even inherited from pdb) has the same
behavior. Asking the writer of rpdb2, I got some excuse (which I didn't
understand) why he had done it that way.

rpdb2 is not pdb.

Below is the output of a Pdb-session I just had:
(eggbasket)dir@client8049:~/software/vc/EggBasket$ nosetests -s
eggbasket.tests.test_model
2008-09-25 14:13:10,374 turbogears.identity.saprovider INFO Loading:
eggbasket.model.VisitIdentity
../home/dir/software/vc/EggBasket/eggbasket/tests/test_model.py(59)test_versionsets()
-vi1 = vset.add_pkg_info(p1)
(Pdb) n

/home/dir/software/vc/EggBasket/eggbasket/tests/test_model.py(60)test_versionsets()

-session.flush()
(Pdb) n
As you can see - mixed-case filenames. Linux though.

There is a *very* simple way for you to check: just create a file called

FooBar.py

and inside that, put

import pdb; pdb.set_trace()
print "hello"
Run that on the windows shell. See if that puts out all lowercase or not. I
can't do that right now as my VBox Windows won't start.

Then we know if PDB is really the culprit.

Apart from that, is that really a problem that the filenames are all lower
case? AFAIK Windows is case-insensitive regarding filenames anyway. So
opening the file by just passing the filename should work seamless.

Diez

[Stef Mientki]

Diez B. Roggisch wrote:

>Yes I'm pretty sure, two reasons:
1. when I perform a step_into, jumping into a file that doesn't have
breakpoints itself (meaning my program doesn't even know of this file),
pdb returns a lowercase filename

What has that to do with potential output postprocessing?

>2. rpdb2 (probably based or even inherited from pdb) has the same
behavior. Asking the writer of rpdb2, I got some excuse (which I didn't
understand) why he had done it that way.

rpdb2 is not pdb.

Below is the output of a Pdb-session I just had:
(eggbasket)dir@client8049:~/software/vc/EggBasket$ nosetests -s
eggbasket.tests.test_model
2008-09-25 14:13:10,374 turbogears.identity.saprovider INFO Loading:
eggbasket.model.VisitIdentity
./home/dir/software/vc/EggBasket/eggbasket/tests/test_model.py(59)test_versionsets()
-vi1 = vset.add_pkg_info(p1)
(Pdb) n

>/home/dir/software/vc/EggBasket/eggbasket/tests/test_model.py(60)test_versionsets()

-session.flush()
(Pdb) n
As you can see - mixed-case filenames. Linux though.

There is a *very* simple way for you to check: just create a file called

FooBar.py

and inside that, put

import pdb; pdb.set_trace()
print "hello"
Run that on the windows shell. See if that puts out all lowercase or not. I
can't do that right now as my VBox Windows won't start.

>>import Module1

d:\data_python_25\pylab_works\module1.py(3)<module >()

-print "hello"
(Pdb)

Then we know if PDB is really the culprit.

So pdb is the problem.

Apart from that, is that really a problem that the filenames are all lower
case? AFAIK Windows is case-insensitive regarding filenames anyway. So
opening the file by just passing the filename should work seamless.

Yes windows is,
but Python is not.
My program should run on Windows and Linux (and maybe a few others).
By converting everything to lowercase, on Linux I can't distinguishes
between 2 files with the same name but a different case
(btw, giving 2 files the same name, only differing in case, looks like a
bad idea to me).

And yes I could switch to lowercase in case I'm on a windows machine,
but my program is too beautiful to pollute the code with these kind of
unnecessary statements ;-)

cheers,
Stef

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

[OKB (not okblacke)]

Stef Mientki wrote:

>import Module1

d:\data_python_25\pylab_works\module1.py(3)<module >()

-print "hello"
(Pdb)

>Then we know if PDB is really the culprit.

So pdb is the problem.

Yep, it does the same thing for me.

>Apart from that, is that really a problem that the filenames are
all lower case? AFAIK Windows is case-insensitive regarding
filenames anyway. So opening the file by just passing the filename
should work seamless.

Yes windows is,
but Python is not.
My program should run on Windows and Linux (and maybe a few
others). By converting everything to lowercase, on Linux I can't
distinguishes between 2 files with the same name but a different
case (btw, giving 2 files the same name, only differing in case,
looks like a bad idea to me).

Hmmm, but I don't understand what you're doing here. Are you
somehow storing the filename that pdb outputs and you need to use it
later on a potentially different OS? If the case is preserved in pdb on
linux, then presumably running it on linux will be fine, right? It's
only a problem if you somehow try to use a filename created by windows-
pdb to open a file (the same file, somehow) on linux.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

[Stef Mientki]

OKB (not okblacke) wrote:

Stef Mientki wrote:

>>>>import Module1
>
d:\data_python_25\pylab_works\module1.py(3)<modu le>()

-print "hello"
(Pdb)

>>Then we know if PDB is really the culprit.

So pdb is the problem.

Yep, it does the same thing for me.

>>Apart from that, is that really a problem that the filenames are
all lower case? AFAIK Windows is case-insensitive regarding
filenames anyway. So opening the file by just passing the filename
should work seamless.

Yes windows is,
but Python is not.
My program should run on Windows and Linux (and maybe a few
others). By converting everything to lowercase, on Linux I can't
distinguishes between 2 files with the same name but a different
case (btw, giving 2 files the same name, only differing in case,
looks like a bad idea to me).

Hmmm, but I don't understand what you're doing here. Are you
somehow storing the filename that pdb outputs and you need to use it
later on a potentially different OS? If the case is preserved in pdb on
linux, then presumably running it on linux will be fine, right? It's
only a problem if you somehow try to use a filename created by windows-
pdb to open a file (the same file, somehow) on linux.

1. I've a multitab editor.
2. When a breakpoint is reached,
3. I check if the file specified in pdb output, is already open in one
of the editor tabs,
4. if not, I open a new tab with the correct file,
5. I focus the correct editor tab and jump to the line specified by pdb.
6. After that I should be able to inspect the surrounding of the
breakpoint, so I need the modules name.

For 3 I need to compare filenames, the editor contains the case
sensitive name, pdb not.
For 6 I also need the case sensitive filename, but probably there's
another way to get the modules name.

For 3, I can indeed compare the lowercase version of both,
probably I'll do that for the moment.

thanks guys for the suggestions
Stef

[Stef Mientki]

I found a partial workaround that is good enough for me:

def Get_Windows_Filename ( FileName ) :
if os.name == 'nt' :
File = os.path.splitext ( FileName .lower ())[0]
return glob.glob ( File + '.p?' )
return FileName

This will translate the filename into the correct case, but not the path.

I also looked at os.path.walk, but that's too slow for me,
because getting the path correct means I have to start at the root.

cheers,
Stef

[Diez B. Roggisch]

Stef Mientki schrieb:

OKB (not okblacke) wrote:

>Stef Mientki wrote:

>>>>>import Module1
>>
d:\data_python_25\pylab_works\module1.py(3)<mod ule>()

-print "hello"
(Pdb)
Then we know if PDB is really the culprit.
So pdb is the problem.

Yep, it does the same thing for me.

>>>Apart from that, is that really a problem that the filenames are
all lower case? AFAIK Windows is case-insensitive regarding
filenames anyway. So opening the file by just passing the filename
should work seamless.
Yes windows is,
but Python is not.
My program should run on Windows and Linux (and maybe a few
others). By converting everything to lowercase, on Linux I can't
distinguishes between 2 files with the same name but a different
case (btw, giving 2 files the same name, only differing in case,
looks like a bad idea to me).

Hmmm, but I don't understand what you're doing here. Are you
somehow storing the filename that pdb outputs and you need to use it
later on a potentially different OS? If the case is preserved in pdb
on linux, then presumably running it on linux will be fine, right?
It's only a problem if you somehow try to use a filename created by
windows-
pdb to open a file (the same file, somehow) on linux.

1. I've a multitab editor.
2. When a breakpoint is reached,
3. I check if the file specified in pdb output, is already open in one
of the editor tabs,
4. if not, I open a new tab with the correct file,
5. I focus the correct editor tab and jump to the line specified by pdb.
6. After that I should be able to inspect the surrounding of the
breakpoint, so I need the modules name.

For 3 I need to compare filenames, the editor contains the case
sensitive name, pdb not.
For 6 I also need the case sensitive filename, but probably there's
another way to get the modules name.

For 3, I can indeed compare the lowercase version of both,
probably I'll do that for the moment.

You can do that based on the OS - do it on windows (as it doesn't care.
Actualy, OSX doesn't as well), don't do it on posix systems.

Diez

[MRAB]

On Sep 25, 8:38*pm, Stef Mientki <[e-mail]:

I found a partial workaround that is good enough for me:

def Get_Windows_Filename ( FileName ) :
* if os.name == 'nt' :
* * File = os.path.splitext ( FileName .lower ())[0]
* * return glob.glob ( File + '.p?' )
* return FileName

This will translate the filename into the correct case, but not the path.

I also looked at os.path.walk, but that's too slow for me,
because getting the path correct means I have to start at the root.

You could try win32api.GetLongPathName(...). However, I've found that
some parts of the path are converted to the correct case but other
parts aren't:

>>print win32api.GetLongPathName(r"c:\documents and settings\administrator\desktop\foobar.py")

c:\documents and settings\administrator\Desktop\FooBar.py

How does your solution compare to using os.listdir(...) instead of
glob?

[Fredrik Lundh]

Stef Mientki wrote:

1. I've a multitab editor.
2. When a breakpoint is reached,
3. I check if the file specified in pdb output, is already open in one
of the editor tabs,
4. if not, I open a new tab with the correct file,
5. I focus the correct editor tab and jump to the line specified by
pdb.
6. After that I should be able to inspect the surrounding of the
breakpoint, so I need the modules name.

For 3 I need to compare filenames, the editor contains the case
sensitive name, pdb not.

pdb uses os.path.abspath and os.path.normcase to normalize filenames so
they can be safely compared (see the canonic method in bdb.py).

I suggest you do the same in your editor; e.g:

pdb_filename = ...

for buffer in editor_buffers:
filename = os.path.normcase(os.path.abspath(buffer.filename))
if pdb == filename:
... found it ...
break

</F>

[Stef Mientki]

Fredrik Lundh wrote:

Stef Mientki wrote:

1. I've a multitab editor.
2. When a breakpoint is reached,
3. I check if the file specified in pdb output, is already open in one
of the editor tabs,
4. if not, I open a new tab with the correct file,
5. I focus the correct editor tab and jump to the line specified by
pdb.
6. After that I should be able to inspect the surrounding of the
breakpoint, so I need the modules name.

For 3 I need to compare filenames, the editor contains the case
sensitive name, pdb not.

pdb uses os.path.abspath and os.path.normcase to normalize filenames
so they can be safely compared (see the canonic method in bdb.py).

I suggest you do the same in your editor; e.g:

Frederik thanks for the clarification.

I don't think your suggestion is a good one.
If a filename has uppercase characters in it,
the END-USER has done that for some kind of reason.
I as a programmer have to respect the arguments of the END-USER,
(whatever they are),
so I need to visualize the real filename.

Secondly thoughtless copying of current behavior, doesn't bring any
progress,
and I think that's one of the reasons why we're still burdened by
inventions done 20 years ago,
e.g. "do you want to save your changes ?".

cheers,
Stef

>
pdb_filename = ...

for buffer in editor_buffers:
filename = os.path.normcase(os.path.abspath(buffer.filename))
if pdb == filename:
... found it ...
break

</F>

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

[Steven D'Aprano]

On Fri, 26 Sep 2008 01:46:15 +0200, Stef Mientki wrote:

Secondly thoughtless copying of current behavior, doesn't bring any
progress,
and I think that's one of the reasons why we're still burdened by
inventions done 20 years ago,
e.g. "do you want to save your changes ?".

I click No about 50% of the time, and Yes Of Course You Stupid Machine
the other 50% of the time. Until they have a computer capable of reading
my mind, I'm curious what alternative you'd suggest.
--
Steven

[Stef Mientki]

Steven D'Aprano wrote:

On Fri, 26 Sep 2008 01:46:15 +0200, Stef Mientki wrote:

>Secondly thoughtless copying of current behavior, doesn't bring any
progress,
and I think that's one of the reasons why we're still burdened by
inventions done 20 years ago,
e.g. "do you want to save your changes ?".

I click No about 50% of the time, and Yes Of Course You Stupid Machine
the other 50% of the time. Until they have a computer capable of reading
my mind, I'm curious what alternative you'd suggest.

Sorry to hear that you waste half of your time,
maybe it's time to find yourself another job ;-)

cheers,
Stef

[r0g]

Steven D'Aprano wrote:

On Fri, 26 Sep 2008 01:46:15 +0200, Stef Mientki wrote:

>Secondly thoughtless copying of current behavior, doesn't bring any
progress,
and I think that's one of the reasons why we're still burdened by
inventions done 20 years ago,
e.g. "do you want to save your changes ?".

I click No about 50% of the time, and Yes Of Course You Stupid Machine
the other 50% of the time. Until they have a computer capable of reading
my mind, I'm curious what alternative you'd suggest.

Agreed, it's pretty handy, especially since every program and its dog
decided to sprout tabs everywhere.
Roger.

[Fredrik Lundh]

Stef Mientki wrote:

I don't think your suggestion is a good one.
If a filename has uppercase characters in it,
the END-USER has done that for some kind of reason.

I explain how pdb works and show you how to solve the specific
comparison problem you mentioned in your post, and you start ranting
because it doesn't solve all your problems? what's wrong with you?

</F>

[Michael Torrie]

Steven D'Aprano wrote:

On Fri, 26 Sep 2008 01:46:15 +0200, Stef Mientki wrote:

>Secondly thoughtless copying of current behavior, doesn't bring any
progress,
and I think that's one of the reasons why we're still burdened by
inventions done 20 years ago,
e.g. "do you want to save your changes ?".

I click No about 50% of the time, and Yes Of Course You Stupid Machine
the other 50% of the time. Until they have a computer capable of reading
my mind, I'm curious what alternative you'd suggest.

It's well known that just using "Yes" and "No" in a dialog box is very,
very poor UI design. In many cases it leads to confusion. Especially
when the dialog box has both a statement and a question, which many do.
The correct and proper way is to use only verbs in the buttons. For
example instead of yes/no to the question of saving work before exiting,
you'd use "save" and "don't save." That's extremely clear even if you
don't quite understand the statement and question the dialog is asking.

Certainly the human-interface guidelines on the more sane systems out
there (OS X, Gnome) disallow the use of yes/no buttons in dialog boxes.