bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problem with line buffered IO when no tty


From: Steven W. Orr
Subject: Problem with line buffered IO when no tty
Date: Thu, 07 Jul 2011 08:36:19 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11

I have a problem with whether things should or should not be line buffered vs. fully buffered. Here's the deal:


#! /bin/bash

sleep 6
cat <<EOF
Here are two
lines to stdout.
EOF
sleep 6
cat <<EOF 1>&2
And two more
to stderr
EOF
exit 22

When I run this program, it does what it's supposed to do. I get two lines of output going to stdout (after 6 seconds) and then I get two more lines to stderr (after another 6 seconds).

Now the fun begins: I run the same program using ssh. Because I'm using ssh, the program is not running from a console, and so, should be setting its output buffers to fully buffered (i.e., not line buffered). In fact, if I just run the tty command using ssh, the answer I get back is "not a tty".

But, I actually do get line buffered IO. I get the stdout stuff as it happens, and the stderr stuff when that happens.

Why do I care you ask? I care because the remote command I'm running was previously written in bash and now it got translated to python. It takes about 20 minutes to run. Now that it's in python, it runs the same way when run locally, but when I run it through ssh, I see *no* output or err channel info till completion. (I used to see lots of progress messages.) I can demonstrate the same result with a small python program:

[swagent@kodiak ~]$ cat xxx.py
#! /usr/bin/python

import time
import sys

time.sleep(6)
print """Here are two
lines to stdout."""
time.sleep(6)
print >> sys.stderr, """And two more
to stderr"""
sys.exit(22)

If you run this program locally, it does the same thing. BUT! if you run it remotely, the two channels all block up till program exit and it all comes out in one squirt.

GNU bash, version 4.0.35(1)-release (x86_64-redhat-linux-gnu)

So, my question is this: Is this a bug in bash and python is doing it right? Or is this some enhancement that bash did to always get line buffering? Or is there another explanation?

TIA

--
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]