Problem!!

[amir chaouki]

i have written code on linux for parsing text files and it works great
but when i try to run it on windows it goes crazy, do you have any
idea???

 

[Irmen de Jong]

i have written code on linux for parsing text files and it works great
but when i try to run it on windows it goes crazy, do you have any
idea???

No, I misplaced my crystal ball.

Irmen


P.S. http://www.catb.org/~esr/faqs/smart-questions.html

 

[rantingrick]

i have written code on linux for parsing text files and it works great
but when i try to run it on windows it goes crazy, do you have any
idea???

psst: you should show us the code first.

 

[Chris Angelico]

i have written code on linux for parsing text files and it works great
but when i try to run it on windows it goes crazy, do you have any
idea???

If you share your code, we may be able to help. Alternatively, here's
a few differences to look at:

1) Filenames - if you have a literal for your file name,
"/home/foobar/file" will work, but "c:\path\newfile.txt" won't -
backslash is a special character. Make it a raw string:
r"c:\path\newfile.txt" - that will work.

2) End of line characters. If you divide the contents of the file on
the "\n" character, and then try to work with the end of each line,
you may find that the string has a "\r" character at the end.

3) What Irmen de Jong said.

Chris Angelico

 

[amir chaouki]

the problem is when i use the seek function on windows it gives me
false results other then the results on *ux. the file that i work with
are very large about 10mb.

 

[Grant Edwards]

i have written code on linux for parsing text files and it works great
but when i try to run it on windows it goes crazy, do you have any
idea???

Yes.

 

[milosh zorica]

filenames and the crlf / eof thing come to my mind first

linux and windows handle files all different

Yes.

--
Grant Edwards               grant.b.edwards        Yow! LOOK!!  Sullen
                                 at              American teens wearing
                             gmail.com            MADRAS shorts and "Flock of
                                                  Seagulls" HAIRCUTS!

--
Milosh Zorica
http://www.linkedin.com/in/miloshzorica | www.coroflot.com/miloshz

http://tangoinabox.co.uk
Tango in a Box - Online Media Production, the Tango Principles Applied -
Born in Argentina, Growing up Globally

+1 310 601 4396 | +44 20 8144 5294 | +54 9 11 3515 7187

 

[TheSaint]

No, I misplaced my crystal ball.

I'm waiting mine, brand new in HD , with remote control

 

[Gregory Ewing]

I'm waiting mine, brand new in HD , with remote control

The new digital models are great. But there's a
distressing tendency for visions to come with
DRM protection these days, so you can only share
them with at most 5 other users. :-(

 

[Steven D'Aprano]

the problem is when i use the seek function on windows it gives me
false results

What do you mean "false results"? What does this even mean?

Please show us:

* what you do
* what result you expect
* what result you actually get

 

[Nobody]

the problem is when i use the seek function on windows it gives me
false results other then the results on *ux. the file that i work with
are very large about 10mb.

This is probably an issue with how the underlying C functions behave on
Windows, related to the CRLF<->LF conversions when a file is opened in
text mode.

The Python library documention for the .seek() method says:

If the file is opened in text mode (without 'b'), only offsets returned
by tell() are legal. Use of other offsets causes undefined behavior.

IOW, you can't use computed offsets with files opened in text mode
(although in practice this will work for platforms other than Windows). If
you want to use computed offsets, open the file in binary mode and strip
the trailing CRs yourself.

And 10MB isn't "very large"; it's not even "large". You normally only
start running into problems with files which are 2GiB (2,147,483,648
bytes) or more (i.e. if you can't fit the size into a signed 32-bit
integer).