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

Discussion in 'Python' started by Prabhu Ramachandran, Aug 16, 2004.

  1. Hi,

    Many thanks for taking the time to respond.

    >>>>> "TP" == Tim Peters <> 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
    Prabhu Ramachandran, Aug 16, 2004
    #1
    1. Advertising

  2. On Mon, 16 Aug 2004 00:34:47 -0400, rumours say that Prabhu Ramachandran
    <> 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
    Christos TZOTZIOY Georgiou, Aug 16, 2004
    #2
    1. Advertising

  3. On Mon, 16 Aug 2004 14:12:54 +0300, rumours say that Christos "TZOTZIOY"
    Georgiou <> 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
    Christos TZOTZIOY Georgiou, Aug 16, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Prabhu Ramachandran

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

    Prabhu Ramachandran, Aug 15, 2004, in forum: Python
    Replies:
    0
    Views:
    430
    Prabhu Ramachandran
    Aug 15, 2004
  2. Tim Peters
    Replies:
    0
    Views:
    604
    Tim Peters
    Aug 15, 2004
  3. N. Volbers
    Replies:
    3
    Views:
    360
    =?iso-8859-1?q?Lars_Gust=E4bel?=
    Jun 30, 2005
  4. Ben Temperton
    Replies:
    1
    Views:
    249
    Emile van Sebille
    Jun 14, 2012
  5. Replies:
    3
    Views:
    127
    Andreas Perstinger
    May 14, 2013
Loading...

Share This Page