SSH output isn't line buffered?












32















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)










share|improve this question



























    32















    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)










    share|improve this question

























      32












      32








      32


      7






      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)










      share|improve this question














      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)







      ssh






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Oct 3 '11 at 2:48









      David WoleverDavid Wolever

      1,30421214




      1,30421214






















          3 Answers
          3






          active

          oldest

          votes


















          42














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






          share|improve this answer
























          • 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 '18 at 13:35



















          23














          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.)






          share|improve this answer


























          • 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



















          5














          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







          share|improve this answer

























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f21920%2fssh-output-isnt-line-buffered%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            42














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






            share|improve this answer
























            • 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 '18 at 13:35
















            42














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






            share|improve this answer
























            • 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 '18 at 13:35














            42












            42








            42







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






            share|improve this answer













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







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Oct 3 '11 at 2:55









            Ryan FoxRyan Fox

            53654




            53654













            • 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 '18 at 13:35



















            • 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 '18 at 13:35

















            didn't help, unfortunately. This also might be problem with MTU, but neither of it helped

            – Nick Roz
            Sep 9 '16 at 23:48





            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 '18 at 13:35





            See Magnus' comment below ref using -tt - that worked for me when -t didn't.

            – Tom Dalton
            Mar 26 '18 at 13:35













            23














            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.)






            share|improve this answer


























            • 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
















            23














            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.)






            share|improve this answer


























            • 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














            23












            23








            23







            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.)






            share|improve this answer















            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.)







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Oct 3 '11 at 10:59









            David Wolever

            1,30421214




            1,30421214










            answered Oct 3 '11 at 3:25









            Dave VanderviesDave Vandervies

            23112




            23112













            • 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



















            • 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

















            An anonymous user suggests that stdout is fully buffered, not line buffered

            – Michael Mrozek
            Oct 3 '11 at 3:53





            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





            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











            5














            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







            share|improve this answer






























              5














              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







              share|improve this answer




























                5












                5








                5







                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







                share|improve this answer















                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








                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited 18 mins ago









                PRY

                2,55831026




                2,55831026










                answered Nov 23 '17 at 8:06









                Magnus BergMagnus Berg

                5111




                5111






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f21920%2fssh-output-isnt-line-buffered%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Loup dans la culture

                    How to solve the problem of ntp “Unable to contact time server” from KDE?

                    ASUS Zenbook UX433/UX333 — Configure Touchpad-embedded numpad on Linux