Bug on Python2.3.4 [FreeBSD]?
merkosh at hadiko.de
Fri Aug 12 16:40:08 EDT 2005
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
> 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
>>> 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
The problem is easyly fixed by appending a f.seek(0) after opening the file,
but the position of the fp is strange.
More information about the Python-list