Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

After a recent re-install of Cygwin I've been experiencing some odd behavior -- in that terminal output from a running application is not showing up when written, but will suddenly pop into existence under certain conditions.

For my particular situation, I'm running a Django server:

python manage.py runserver

This should spit out several status messages to the terminal as the server spins up, and should also display server requests and replies (in addition to Python print statements). None of these are showing up.

However, when I modify a file that is part of the Django app the server restarts automatically (as it should) and all the output suddenly appears for the previous session.

A previous install of Cygwin worked fine.

The only known difference I have is that the previous install using the Cygwin Python (in /usr/bin) while my new install uses the Windows Pyton (in /cygdrive/c/Python27). This was done for MySQL data connectivity purposes.

An addition oddity, which may point to a larger issue, is that after I run the server Cygwin requires 2 clicks on the close button (top-right 'X') to close the terminal window. The first click renders the terminal useless, but the window itself remains; a second click removes it from the screen.

Has anyone encountered a situation where Cygwin is not updating the terminal output, and located a handy fix?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

The problem here is a combination of the different Python installations and Python's "flushing" behaviour.

Flushing refers to writing something from memory to file or screen. When a well-designed program is writing something to a screen, it will detect that and write ("flush") it to the screen immediately, so it can be seen immediately. However, if a program is writing to a file on disk, making lots of small writes to a file is much slower than making one big one, so it will "buffer" small writes until there's a chunk of them to flush to the file at once. This is what Python does.

The problem you're seeing is that Cygwin's Python understands that MinTTY is a terminal, and so flushes to it frequently, but Windows Python can't tell the difference between a MinTTY terminal and a file on disk. It assumes what it's writing to is a file, so it queues up writes and flushes them in batches (the app restarting will trigger this), rather than flushing each message as it appears. If you waited long enough (at a guess, enough for 64kb worth of messages to be queued up), you'd see them all being written to screen at once, too.

There are two solutions: either find a way to work around your MySQL issues so you can use Cygwin Python, or use Windows Python from a Windows cmd shell, which would be correctly detected as a terminal, and thus produce the correct flushing behaviour.

You may also have some luck disabling Python's buffering behaviour. If you run Python with a -u option, or add sys.stdout.flush() after print statements, that will prevent Python buffering up messages, and cause it to flush them to screen immediately.

share|improve this answer
    
See also stackoverflow.com/questions/230751/… (and presumably its duplicate, although I didn't check that). –  me_and Mar 21 '13 at 0:13
    
Thank you me_and for the full description! I'm using it out of the cmd prompt at the moment. Hopefully my reason for "needing" the Windows version of Python is wrong and I can go back to the Cygwin version after checking on some things. –  Evil Closet Monkey Mar 21 '13 at 16:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.