Can I disable buffering for tr

Commands generally don't buffer their input. They would do a read() for a large chunk, but when reading from a pipe, if there aren't that many bytes in the pipe, the read() system call will return with as many characters there are and the application will generally work with that if it can.

A notable exception to that is mawk which will keep re-read()ing until the input buffer is full.

Applications do buffer their output (stdout) though. The usual behaviour is that if the output is going to a tty, then the buffering will be line-wise (that is, it won't start writing to stdout until it has a full line to output, or a block-full for very long line), while for every other type of file, the buffering is by blocks (that is, it won't start writing until is has one block full to write (something like 4KiB/8KiB... depends on the software and system)).

So in your case LongRunningCommand likely buffers its output by blocks (since its output is a pipe and not a tty), and tr likely buffers its output by line since its output is probably the terminal.

But, since you remove every newline character from its output, it will never output a line, so the buffering will be by block.

So here you want to disable buffering for both LongRunningCommand and tr. On GNU or FreeBSD systems:

stdbuf -o0 LongRunningCommand | stdbuf -o0 tr '\n' ,

Note that if you want to join the lines with a comma, a better approach is to use paste -sd , -. That way the output will be terminated by a newline character (you'll probably still need to disable buffering).

To replace newlines with ",", you can run

awk '{ printf "%s,", $0 }'

GNU awk (gawk) and Solaris nawk will run with line buffering on stdin and no buffering stdout when the output is to a terminal. If your awk is mawk, which happens on Ubuntu, you can give it the -W interactive option to get that same buffering behavior.