42

Is it possible to read stdin as binary data in Python 2.6? If so, how?

I see in the Python 3.1 documentation that this is fairly simple, but the facilities for doing this in 2.6 don't seem to be there.

If the methods described in 3.1 aren't available, is there a way to close stdin and reopen in in binary mode?

Just to be clear, I am using 'type' in a MS-DOS shell to pipe the contents of a binary file to my python code. This should be the equivalent of a Unix 'cat' command, as far as I understand. But when I test this out, I always get one byte less than the expected file size.


The reason I'm going the Java/JAR/Jython route is because one of my main external libraries is only available as a Java JAR. But unfortunately, I had started my work as Python. It might have been easier to convert my code over to Java a while ago, but since this stuff was all supposed to be compatible, I figured I would try trucking through it and prove it could be done.

In case anyone was wondering, this is also related to this question I asked a few days ago.

Some of was answered in this question.

So I'll try to update my original question with some notes on what I have figured out so far.

Neuron
  • 5,141
  • 5
  • 38
  • 59
danielshiplett
  • 669
  • 1
  • 9
  • 20

7 Answers7

30

From the docs (see here):

The standard streams are in text mode by default. To write or read binary data to these, use the underlying binary buffer. For example, to write bytes to stdout, use sys.stdout.buffer.write(b'abc').

But, as in the accepted answer, invoking python with a -u is another option which forces stdin, stdout and stderr to be totally unbuffered. See the python(1) manpage for details.

See the documentation on io for more information on text buffering, and use sys.stdin.detach() to disable buffering from within Python.

Prestel Nué
  • 831
  • 2
  • 9
  • 12
24

Here is the final cut for Linux/Windows Python 2/3 compatible code to read data from stdin without corruption:

import sys

PY3K = sys.version_info >= (3, 0)

if PY3K:
    source = sys.stdin.buffer
else:
    # Python 2 on Windows opens sys.stdin in text mode, and
    # binary data that read from it becomes corrupted on \r\n
    if sys.platform == "win32":
        # set sys.stdin to binary mode
        import os, msvcrt
        msvcrt.setmode(sys.stdin.fileno(), os.O_BINARY)
    source = sys.stdin

b = source.read()
anatoly techtonik
  • 19,847
  • 9
  • 124
  • 140
15

Use the -u command line switch to force Python 2 to treat stdin, stdout and stderr as binary unbuffered streams.

C:> type mydoc.txt | python.exe -u myscript.py
jfs
  • 399,953
  • 195
  • 994
  • 1,670
Dan Menes
  • 6,667
  • 1
  • 33
  • 35
  • I have tested this with 'type' and it appears to work. That is, if I leave out the -u flag, I get one fewer character per line. – Dan Menes May 17 '10 at 19:14
  • Cool. Thanks for the test. So, just because I like you so much, any idea how to pass the '-u' option through the JarRunner.java class that is used to fire off Jython through an executable JAR file? I know. I never do anything the easy way. – danielshiplett May 17 '10 at 19:25
  • 1
    According to docs, setting the PYTHONUNBUFFERED environment variable will have the same effect. Not sure if that helps. – Dan Menes May 17 '10 at 19:32
  • 5
    Even easier, it appears that all you need to do is: sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb', 0) That will reopen the fd in unbuffered 'binary' mode. – danielshiplett May 17 '10 at 19:57
  • 1
    @thebeav: Oddly enough that doesn't work on my system. I don't know if that's because I'm using CPython instead of Jython, or if it's because I'm running Windows XP Pro, and "type" behaves differently, or its because there is a magnetic anomaly in the Manassas area that makes computers do different things. FWIW, I tried a number of ways to get Python to change the file mode after the interpreter had started, including accessing the C runtime's "setmode" function via ctypes. Nothing works for me. – Dan Menes May 17 '10 at 20:27
  • 1
    Uh-oh. I smell a portability issue. Thanks for the info. I guess I'm going to have to do some fairly rigorous testing on multiple platforms. I hope this doesn't have to do with the JVM in use. – danielshiplett May 18 '10 at 13:02
9

If you still need this... This simple test i've used to read binary file that contains 0x1A character in between

import os, sys, msvcrt

msvcrt.setmode (sys.stdin.fileno(), os.O_BINARY)
s = sys.stdin.read()
print len (s)

My test file data was:

0x23, 0x1A, 0x45

Without setting stdin to binary mode this test prints 1 as soon it treats 0x1A as EOF. Of course it works on windows only, because depends on msvcrt module.

Frazil
  • 107
  • 1
  • 2
  • 1
    But Windows is the only system where most people will run into a problem, so this should be an acceptable solution. – Mark Ransom Jan 22 '14 at 05:04
  • 1
    This is the correct solution for Python 2 to retrieve the raw bytes from stdin on Windows. On Unix, there is no difference between binary and normal mode. See this thread: http://code.activestate.com/lists/python-list/20426/ (re-opening stdin in raw (binary) mode?) – Dr. Jan-Philip Gehrcke Feb 20 '14 at 15:29
  • 1
    I was getting a `ValueError: insecure string pickle` exception on Windows when trying to un`pickle` data that had been written to `stdout` in one process which was being piped into another. The solution turned out to be adding a `msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)` in the process that wrote the data. – martineau Apr 11 '16 at 18:52
3

You can perform an unbuffered read with:

os.read(0, bytes_to_read)

with 0 being the file descriptor for stdin

Jay
  • 2,535
  • 3
  • 32
  • 44
0

To read binary data from stdin (in Python 2.4–2.7, 3.0–, both Unix and Windows), do this:

import os, sys
if sys.platform.startswith('win'):
    try:
        __import__('msvcrt').setmode(sys.stdout.fileno(), os.O_BINARY)
    except ImportError:
        pass
sys.stdin = os.fdopen(sys.stdin.fileno(), 'rb')
...
print(sys.stdin.read(4096))

To read binary data from stdin, without modifying sys.stdin (in Python 2.4–2.7, 3.0–, both Unix and Windows), do this:

import os, sys
f = os.fdopen(os.dup(sys.stdin.fileno()), 'rb')
if sys.platform.startswith('win'):
    try:
        __import__('msvcrt').setmode(f.fileno(), os.O_BINARY)
    except ImportError:
        pass
...
print(f.read(4096))

To read binary data unbuffered (i.e. as soon as it is available to the Python process) from a file object, while putting the underlying file descriptor to binary mode, do this (in Python 2.4–2.7, 3.0–, both Unix and Windows):

import os, sys
f = sys.stdin  # Or anything other file object.
if sys.platform.startswith('win'):
    try:
        __import__('msvcrt').setmode(f.fileno(), os.O_BINARY)
    except ImportError:
        pass
...
print(os.read(f.fileno(), 4096))

For unbuffered binary reads, it's tempting to do f = os.fdopen(f.fileno(), 'rb', 0), but in Python 2.x it doesn't make the read (i.e. f.read(4096)) unbuffered, it would still wait indefinitely for more input until the 4096 bytes are filled or EOF is reached.

pts
  • 80,836
  • 20
  • 110
  • 183
-3
import sys

data = sys.stdin.read(10) # Read 10 bytes from stdin

If you need to interpret binary data, use the struct module.

Yann Ramin
  • 32,895
  • 3
  • 59
  • 82
  • If I then call sys.stdin.read() with no parameter, it should read all the binary data that was piped in, correct? How then do I determine the length correctly? len(data) returns the incorrect value if the last byte of the data was a zero. How do you check and correct for this situation? – danielshiplett May 17 '10 at 17:15
  • 2
    `len` counts the \x00 characters in the string. Python does not have null terminated strings. `len("Hello\x00") == 6` – Yann Ramin May 17 '10 at 17:27
  • I wonder then if it might be the 'type' command from the MS-DOS shell that is causing the loss of the final byte? I guess I will have to test the equivalent on Linux. Thanks. – danielshiplett May 17 '10 at 17:52
  • 2
    I think this answer misses the point of the question: if the stream is in "text" mode, the results from `read()` might be different than if the stream is in "binary" mode. – Brent Bradburn Feb 05 '13 at 19:34
  • 3
    It might corrupt input stream on Windows e.g., `'\r\n'` -> `'\n'`. Also, on Python 3 `sys.stdin.read()` returns Unicode strings e.g., `b'\xf0\x9f\x96\x96'` -> `'\U0001f596'` (4 bytes -> 1 chararcter). It is undesirable behaviour if input is not text. – jfs Nov 16 '13 at 01:01