AW: Write to a binary file

[Thomi Aurel RUAG A]

Hy Mike
Thanks for your links, unfortunately they weren't very usefull for my
specific problem.

Hy Grant Edwards
Thanks for your hints.
A simplified test programm to compare the function for opening a file i
used ("file()") and your suggested "os.open()" showed different
behaviour.

My simple testprogramm:

--- START ---
import os

msg = chr(0x02) + chr(0x36) + chr(0x00) + chr(0x01) + chr(0x0a) +
chr(0xb0) + chr(0x77)

f = os.open('/dev/pytest', os.O_RDWR)
os.write(f,msg)
os.close(f)

f = file('/dev/pytest', 'wb')
f.write(msg)
f.close()
--- END ---

The "pytest" device is a very simple device-driver which prints out
(using "printk()") the buffer delivered to the write function in a
hexadecimal format ("Pytest write> [buffer in hex format]").

The output was:
--- Start ---
Pytest write> 02 36 00 01 0a b0 77
Pytest write> 02 36 00 01 0a
Pytest write> b0 77
--- END ---

Using os.open will work for me, i wasn't aware of the existence of
several file interaces.

Thanks for your help
regards

Aurel

 

[Grant Edwards]

A simplified test programm to compare the function for opening
a file i used ("file()") and your suggested "os.open()" showed
different behaviour.

My simple testprogramm:

--- START ---
import os

msg = chr(0x02) + chr(0x36) + chr(0x00) + chr(0x01) + chr(0x0a) +
chr(0xb0) + chr(0x77)

f = os.open('/dev/pytest', os.O_RDWR)
os.write(f,msg)
os.close(f)

f = file('/dev/pytest', 'wb')
f.write(msg)
f.close()
--- END ---

The "pytest" device is a very simple device-driver which
prints out (using "printk()") the buffer delivered to the
write function in a hexadecimal format ("Pytest write> [buffer
in hex format]").

The output was:
--- Start ---
Pytest write> 02 36 00 01 0a b0 77
Pytest write> 02 36 00 01 0a
Pytest write> b0 77
--- END ---

I'm surprised that the normal file object's write method does
that -- especially for a "binary" file. IMO, it's a bug when a
binary file object treats 0x0a differently than other byte
values. But, using the file object to read/write a device is
probably not a good idea because of undefined behavior like
that. File objects also do their own buffering, which I
suspect isn't what you want.

Using os.open will work for me, i wasn't aware of the
existence of several file interaces.

The os.file/open ones are just very thin wrappers around the
corresponding libc routines. The file object contains it's own
buffering and other features that will just get in the way of
what you probably want to do.

 

[Thinker]

A simplified test programm to compare the function for opening
a file i used ("file()") and your suggested "os.open()" showed
different behaviour.

My simple testprogramm:

--- START ---
import os

msg = chr(0x02) + chr(0x36) + chr(0x00) + chr(0x01) + chr(0x0a) +
chr(0xb0) + chr(0x77)

f = os.open('/dev/pytest', os.O_RDWR)
os.write(f,msg)
os.close(f)

f = file('/dev/pytest', 'wb')
f.write(msg)
f.close()
--- END ---

The "pytest" device is a very simple device-driver which
prints out (using "printk()") the buffer delivered to the
write function in a hexadecimal format ("Pytest write> [buffer
in hex format]").

The output was:
--- Start ---
Pytest write> 02 36 00 01 0a b0 77
Pytest write> 02 36 00 01 0a
Pytest write> b0 77
--- END ---

I'm surprised that the normal file object's write method does
that -- especially for a "binary" file. IMO, it's a bug when a
binary file object treats 0x0a differently than other byte
values. But, using the file object to read/write a device is
probably not a good idea because of undefined behavior like
that. File objects also do their own buffering, which I
suspect isn't what you want.

Why not try to create a file object with bufsize = 0 ?
for ex:

 

[Gabriel Genellina]

I'm surprised that the normal file object's write method does
that -- especially for a "binary" file. IMO, it's a bug when a
binary file object treats 0x0a differently than other byte
values.

A write() call on a Python file object gets directly translated into a
fwrite() C runtime library call. Any special handling is made inside that
library.

But, using the file object to read/write a device is
probably not a good idea because of undefined behavior like
that. File objects also do their own buffering, which I
suspect isn't what you want.

I agree - using os.open, os.write etc. appears to be the right thing here.

 

[Grant Edwards]

I just ran that on my system (2.4.3), and both versions do a
signle write.

The "pytest" device is a very simple device-driver which
prints out (using "printk()") the buffer delivered to the
write function in a hexadecimal format ("Pytest write> [buffer
in hex format]").

The output was:
--- Start ---
Pytest write> 02 36 00 01 0a b0 77
Pytest write> 02 36 00 01 0a
Pytest write> b0 77
--- END ---

I'm surprised that the normal file object's write method does
that -- especially for a "binary" file. IMO, it's a bug when a
binary file object treats 0x0a differently than other byte
values. But, using the file object to read/write a device is
probably not a good idea because of undefined behavior like
that. File objects also do their own buffering, which I
suspect isn't what you want.

Why not try to create a file object with bufsize = 0 ?
for ex:
---------
fo = file('/dev/pytest', 'wb', 0)
fo.write(....)
fo.close()
--------

That's worth a try, but I can't get the normal method to fail...