Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Trouble with file.seek/file.tell on Win32?

Reply
Thread Tools

Re: Trouble with file.seek/file.tell on Win32?

 
 
Prabhu Ramachandran
Guest
Posts: n/a
 
      08-16-2004
Hi,

Many thanks for taking the time to respond.

>>>>> "TP" == Tim Peters <(E-Mail Removed)> writes:


TP> [Prabhu Ramachandran]
>> I noticed peculiar behavior under Python-2.3.4 under Win32.
>> When I run something like this:
>>
>> f = open('t.txt', 'wb') f.write('1\012'+'2\012'+'3\012')
>> f.close() f = open('t.txt', 'r')


TP> Sorry, you're in trouble already. You can *tell* Windows
TP> that's a text file, but it doesn't contain native Windows
TP> text-file data (it has the wrong kind of line end for
TP> Windows).

Yes, I was aware of that, files with the right line endings did work
fine. I was not aware that files with the wrong line endings under
Win32 could break tell and seek.

Here is what happened. I was building a self-extracting installer for
a CVS snapshot of MayaVi (using Gordon McMillan's installer). The
file in question is a MayaVi visualization file. This is parsed to
generate a visualization. I use file.tell and file.seek to handle
some backwards compatibility issues (its an ugly hack but works).

The file in question has not changed in years and used to work fine
when I built the installer last time. What I did not realize is that
the file that is distributed with the previous installer had the right
line endings! Here is the wierd part. I work primarily on Linux and
build a zip and tarball using distutils. I take the zip file to a
windows box and have setup scripts to do bulk of the dirty work. It
has worked just fine in all previous attempts (on different machines
with earlier versions of Python). This time I setup a Windows XP
machine with all the software. I got the ZIP file I just built,
unzipped it, and tried to load the example visualization and it
failed. For some reason the line endings were not converted this time
around. I had no explanation as to why that happened. I suspected
that it was the line endings under windows. Since neither the files
or *my* scripts had changed in any way to touch line endings, I
suspected it was a bug with the way Python handled the line endings
this time. It was not distutils either since the MayaVi-1.3.zip file
at sourceforge also has the unix style file. So I assumed that since
nothing relevant had changed with my sources and scripts it must be
Python. I was wrong.

I now realize that the only significant difference is the unzip
utility I used. I used Winzip the last time I built the binaries. A
google search reveals that Winzip does indeed convert line endings by
default. This time I used the standard WinXP tools to unzip the file
and they don't convert line endings. I did not know or suspect that.
So, sorry for the false alarm. I'm happy though that the puzzle is
solved. I'm happy to also learn that bad line endings break tell and
seek. I guess this is a problem on the mac too where lines end with
'\r'. Is this true of OSX?

Anyway, it looks like I should either simply read and write to the
file using the 'rb' and 'wb' modes on all platforms or make sure that
line endings in the file are correct on the platform. I should also
encourage folks to use unzip utilities with care.

[...]

Thanks for the detailed example showing that the problem is not with
Python. Sorry for the bother.

Thanks again.

regards,
prabhu


 
Reply With Quote
 
 
 
 
Christos TZOTZIOY Georgiou
Guest
Posts: n/a
 
      08-16-2004
On Mon, 16 Aug 2004 00:34:47 -0400, rumours say that Prabhu Ramachandran
<(E-Mail Removed)> might have written:

>I'm happy to also learn that bad line endings break tell and
>seek. I guess this is a problem on the mac too where lines end with
>'\r'. Is this true of OSX?


I have little knowledge of OS/X (just playing around with a friends
Apple laptop, can't remember the type), but I assume that there will not
be a problem with OS/X (and do they use '\r' like in the old MacOS, or
do they respect the Linux heritage and use '\n' now? maybe a mix?).

The string "hello\nthere\n" written to a *text* file, has:

12 bytes on *nix
14 bytes on Windows/DOS
12 bytes on OS/X

To read the "t" of "there", one first has to:

f.seek(6) on both *nix and OS/X, text or binary file
f.seek(6) on Win text file
f.seek(7) on Win binary file.
--
TZOTZIOY, I speak England very best,
"Tssss!" --Brad Pitt as Achilles in unprecedented Ancient Greek
 
Reply With Quote
 
 
 
 
Christos TZOTZIOY Georgiou
Guest
Posts: n/a
 
      08-16-2004
On Mon, 16 Aug 2004 14:12:54 +0300, rumours say that Christos "TZOTZIOY"
Georgiou <(E-Mail Removed)> might have written:

[snip correcting myself]

>The string "hello\nthere\n" written to a *text* file, has:
>
>12 bytes on *nix
>14 bytes on Windows/DOS
>12 bytes on OS/X
>


In all cases, if you open the file as text and do a .readline(), you
read a string of length 6; however, only in the Windows/DOS case, f.tell
returns 7, not 6.
--
TZOTZIOY, I speak England very best,
"Tssss!" --Brad Pitt as Achilles in unprecedented Ancient Greek
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
i have no trouble to send , ihave trouble reciving mail --any ideas John Penney Computer Support 4 08-29-2006 08:45 PM
having trouble securing my wireless laptop FireBrick Wireless Networking 2 08-10-2004 12:37 PM
Trouble staying connected to wifi Michael Giroux Wireless Networking 1 08-03-2004 08:33 PM
Trouble connecting in public hot spots Andres Perez Wireless Networking 2 07-16-2004 06:47 PM
trouble with caching or caching the trouble Hypo ASP .Net 6 08-01-2003 07:11 AM



Advertisments