Bug on Python2.3.4 [FreeBSD]?

[Uwe Mayer]

Friday 12 August 2005 22:12 pm David Bolen wrote:
> Which version of FreeBSD are you running?  I thought it might be a
> dependency on needing to seek between reads and writes on a duplex
> stream (which is ANSI), but FreeBSD doesn't require that, at least
> back as far as a 4.7 system I have, and I assume much earlier than
> that.
> 
> One dumb question - are you absolutely sure it wasn't appending?  As
> written, there's no trailing newline on the file, so your final "cat
> test" would produce output where the "testing" was on the same line as
> your next command prompt, and can sometimes be missed visually.
> 
>> Can anyone confirm that? Is there any other way of opening a file for
>> appending instead of a+?
> 
> Well, if you really just want appending, I'd just use "a".  It creates
> the file if necessary but always appends to the end.  Of course, it's
> not set up for reading, but you wouldn't need that for appending.

I was debugging an application I released, on a forreign FreeBSD system:
$ uname -a
FreeBSD hephaistos 4.11-RELEASE FreeBSD 4.11-RELEASE #0: Sun Feb 27 21:09:39
CET 2005     root at olympus.tfp:/storage/obj-4.11/usr/src/sys/OLYMPUS  i386

The application as able to create and write to files, but not to open and
read them.  It seems the file poitner is positioned at the end of a file
when using:

>>> f = open('<filename>', 'a+')

on FreeBSD, but at the beginning of the file on Linux (at least on my Debian
unstable, Python 2.3.4 and 2.3.5; its running on Gentoo Linux and Suse,
too, though I don't know the Python version numbers).
I was assuming the fp was set to 0 in this mode, thus the app was not
working on above FreeBSD and the owner set up a login for me to debug the
situation.

The problem is easyly fixed by appending a f.seek(0) after opening the file,
but the position of the fp is strange.

Thanks,
Ciao
Uwe