I'm running a script on a remote machine like this:

ssh $host "pip install -r /path/to/requirements.txt"

But the output isn't line buffered; instead of seeing one line returned at a time, all the lines (~10) are all printed at once as the connection terminates.

What's up with this? Is there any way to force them to be line buffered?

(also, to state the obvious: when I ssh into $host and run the command “manually”, the output is line buffered, as expected)

up vote 41 down vote accepted

Use ssh -t ... to force a pseudo-tty allocation (which is what you get when you log in normally via ssh.)

  • didn't help, unfortunately. This also might be problem with MTU, but neither of it helped – Nick Roz Sep 9 '16 at 23:48
  • See Magnus' comment below ref using -tt - that worked for me when -t didn't. – Tom Dalton Mar 26 at 13:35

To expand a little bit on Ryan Fox's answer: Many programs (most? - it's the default for any C program) line-buffer stdout when they're talking to a terminal, but fully buffer it otherwise. (The C standard specifies that stdout is initially fully buffered when it "can be determined not to refer to an interactive device".)

So what you're seeing is that the output of the program you're running remotely (as given to stdout) isn't line-buffered; ssh is just passing through what it gets when it gets it. (I think ssh actually does no buffering at all on its output - that would be the least magical way to make sure that the user sees what the remote program intended.)

  • An anonymous user suggests that stdout is fully buffered, not line buffered – Michael Mrozek Oct 3 '11 at 3:53
  • Dave Vandervies has told me out-of-band that he was the one who made the edit, and that it is correct (ie, stdout is initially fully buffered, not line buffered). – David Wolever Oct 3 '11 at 6:05

To expand even more on Ryan Fox's answer, "ssh -t" didn't work for me either, but "ssh -tt" did. See the ssh man page about -t:

Multiple -t options force tty allocation, even if ssh has no local tty

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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