2

[The Question]
Is there some way to have the pipe/tee/write combo write lines immediately? ... if it can be done, what is the trade-off?

[The Backdrop]
My script sends a keypress to the terminal, which is running app.
That keypress causes app to write a marker to its log.
The log is the app's normal screen output (timestamped lines).
The log is being written via | tee -a log

The marker marks the line I want; ie. the timestamped line before the marker.

The problem is that when I then immediately search the log (using sed from the same script), it sometimes returns a previous marker, ie. the most recent marker has not been written to the log yet.

I assume this is a buffering issue, but I'm in unknown territory with that.

Not sure if it matters: The script is elisp. The terminal is emacs terminal emulator with a bash shell.

Peter.O
  • 32,916

1 Answers1

4

I suppose the problem is not tee that I seem to remember do not buffer or at most buffers by lines.

So, if the problem is you app, you can modify its behavior using the stdbuf utility (unless app do its own modifications to stdout buffering). You can use it in this way:

stdbuf -o 0 app args | tee -a log

The -o 0 option configures the stdout of app as unbuffered.

enzotib
  • 51,661
  • Thanks enzo. It sounds good, but unfortunately a version of coreutils with stdbuf isn't in my Ubuntu 10.04 repository... I'll look further into it tomorrow... +1 for now... – Peter.O Dec 10 '11 at 17:26
  • @ferer: see also this question: Turn off buffering in pipe. – enzotib Dec 10 '11 at 17:32
  • @ferer When you're running inside Emacs, you could run the application directly as a subprocess of Emacs and have Emacs write the log by periodically saving the output buffer. – Gilles 'SO- stop being evil' Dec 10 '11 at 21:02
  • @Gilles: Thanks. If I've understood you correctly, you mean that I could run app without running it in the terminal... In this case I can't do that, because app is mplayer, and I would lose the ability to control it via its interactive response to key-presses.
    However, I've found a temporary(?) workaround..
    Each marker is unique, and because mplayer is constantly feeding the log, the buffer is flushed at a constant rate, so the problem occurs only for a short log (a long log takes longer to search). I've simply added a loop to repeat the search until the correct marker turns up.     – Peter.O Dec 11 '11 at 05:16