[SOLVED] Program output waits before being redirected

[cybertron]

I use mbmon to monitor the temperature of my system, and would like to be able to write its output to a file and also read the last line of the file to get the latest values. For some reason, the mbmon output doesn't actually get written to the file until mbmon completes, even though when I run it without redirecting the output I see it all just fine in my terminal as soon as it becomes available. Here's some example output:
[cybertron@TuXP ~]$ mbmon -T 1
28.0
28.0
28.0
28.0
28.0

[cybertron@TuXP ~]$
It continues to print those numbers every five seconds until doomsday or I press ctrl-c (as I did in this case). However, if I redirect the output like this: "mbmon -T 1 > temp.dat", nothing shows up in the file unless I tell mbmon to stop after a certain number of times. Then it just writes them all when it exits, instead of as it outputs them.

I'm stumped as to why I can see the output in the terminal but can't redirect it to a file on the fly. I've even tried using mkfifo to create a named pipe, but that does essentially the same thing, in a pipey kind of way:)

It's not a big deal, but any help would be appreciated. TIA.

[bwkaz]

Maybe mbmon uses the C library isatty() function to figure out whether its output is a TTY or something else (like a file or named pipe)?

If that's the case, then you could run it under expect (somehow -- you'd have to learn the expect lanuage first, though, and I don't have much of an idea how it works), and perhaps log the output that way.

When programs run under expect, then isatty() calls succeed (because expect opens up a pseudo-TTY to talk to the process that it's running). With normal redirection, isatty() fails.

[cybertron]

Well that's a pain. I don't think it's really worth learning a new language to deal with it though. It's just that right now I'm restarting mbmon (which takes more cpu time than just leaving it running) every time I want an updated value for the temperature. I could update more often (and get rid of the wasted cpu cycles) if I could find a way to leave it running, but I guess that's not going to happen. Thanks for the suggestion though.

Just out of curiousity, why would the program care what's happening to its output? As far as I can tell it's just plain text, so it doesn't seem like it would hurt anything to allow it to be redirected.

[bwkaz]

Well, it shouldn't care. But stranger things have happened.

Plus, programs like su and login require their input to be TTYs as a prevention against brute force attacks. If they didn't, then the attacker could create a program that generated tons of passwords and printed them in sequence, then pipe that program's output into su or login.

[cybertron]

That makes sense. I don't really want anyone brute-forcing my computer.

It's odd though, I tried grepping on isatty and didn't get anything. I was hoping maybe I could remove the check and get it working. Oh well, it really isn't a big deal.

[cybertron]

Aha, there's a "sleep" at the end of an infinite loop in it, and when I remove that it writes to the file just fine. Of course, that obviously causes other problems (such as the fact that the output file was over 4 MB in a couple of seconds, among other things). Looks like I'm going to have to read up on my C functions and see if I can figure out how to fix it in a way that works.

Edit: BTW, did I mention that I LOVE open source?:D

[bwkaz]

Try adding an fflush(stdout) call right before the sleep() maybe?

[cybertron]

Thanks! Worked great.:)

[bwkaz]

OK, that's odd, because stdout should be line-buffered (i.e., it should flush itself every time a newline is written).

But hey, if it works, go with it, I guess. :)