Difference between 2>&1 > output.log and 2>&1 | tee output.log

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












28















I wanted to know the difference between the following two commands



2>&1 > output.log 


and



2>&1 | tee output.log


I saw one of my colleague use second option to redirect. I know what 2>&1 does, my only question is what is the purpose of using tee where a simple redirection ">" operator can be used?










share|improve this question















migrated from stackoverflow.com Sep 10 '11 at 22:33


This question came from our site for professional and enthusiast programmers.






















    28















    I wanted to know the difference between the following two commands



    2>&1 > output.log 


    and



    2>&1 | tee output.log


    I saw one of my colleague use second option to redirect. I know what 2>&1 does, my only question is what is the purpose of using tee where a simple redirection ">" operator can be used?










    share|improve this question















    migrated from stackoverflow.com Sep 10 '11 at 22:33


    This question came from our site for professional and enthusiast programmers.




















      28












      28








      28


      16






      I wanted to know the difference between the following two commands



      2>&1 > output.log 


      and



      2>&1 | tee output.log


      I saw one of my colleague use second option to redirect. I know what 2>&1 does, my only question is what is the purpose of using tee where a simple redirection ">" operator can be used?










      share|improve this question
















      I wanted to know the difference between the following two commands



      2>&1 > output.log 


      and



      2>&1 | tee output.log


      I saw one of my colleague use second option to redirect. I know what 2>&1 does, my only question is what is the purpose of using tee where a simple redirection ">" operator can be used?







      shell io-redirection pipe






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Sep 10 '11 at 23:06









      Gilles

      535k12810821599




      535k12810821599










      asked Sep 10 '11 at 0:50









      Chander ShivdasaniChander Shivdasani

      5443711




      5443711




      migrated from stackoverflow.com Sep 10 '11 at 22:33


      This question came from our site for professional and enthusiast programmers.









      migrated from stackoverflow.com Sep 10 '11 at 22:33


      This question came from our site for professional and enthusiast programmers.






















          6 Answers
          6






          active

          oldest

          votes


















          21














          Editorial note



          Please make sure to read the comments on this answer — derobert.




          Original answer



          2>&1 >output.log means first start sending all file handle 2 stuff (standard error) to file handle 1 (standard output) then send that to the file output.log. In other words, send standard error and standard output to the log file.



          2>&1 | tee output.log is the same with the 2>&1 bit, it combines standard output and standard error on to the standard output stream. It then pipes that through the tee program which will send its standard input to its standard output (like cat) and also to the file. So it combines the two streams (error and output), then outputs that to the terminal and the file.



          The bottom line is that the first sends stderr/stdout to the file, while the second sends it to both the file and standard output (which is probably the terminal unless you're inside another construct which has redirected standard output).



          I mention that last possibility because you can have stuff like:



          (echo hello | tee xyzzy.txt) >plugh.txt


          where nothing ends up on the terminal.






          share|improve this answer




















          • 13





            -1 You have the syntax right, but not the semantics. Run cat /doesnotexist 2>&1 >output.txt - you will see see cat: /doesnotexist: No such file or directory displayed to the terminal and output.txt is an empty file. Order of precedence and closure are in play: 2>&1 (dup fd2 from the current fd1), then >output.txt (redirect fd1 to output.txt, not changing anything else). The reason that 2>&1 | is different is because of order of precedence: | before >.

            – Arcege
            Sep 10 '11 at 23:33






          • 5





            This answer is fundamentally wrong in essentially every respect. Many of the answers below are better, but I think this one by Kusalananda is the clearest.

            – Michael Homer
            Jan 22 at 2:46






          • 1





            @user14408: Should you ever make an account on Unix & Linux and claim this answer, please feel free to remove my editorial note once you've addressed the comments.

            – derobert
            Jan 22 at 19:01


















          8














          First command will do the another task:



          After



          2>&1 > output.log 


          the old STDOUT will be saved (copied) in STDERR and then STDOUT will be redirected to file.



          So, stdout will go to file and stderr will go to console.



          And in



           2>&1 | tee output.log


          both streams will be redirected to tee. Tee will duplicate any input to its stdout (the console in your case) and to file (output.log).



          And there is another form of first:



           > output.log 2>&1


          this will redirect both STDOUT and STDERR to the file.






          share|improve this answer






























            7














            Looking at the two commands separately:



            utility 2>&1 >output.log 


            Here, since redirections are processed in a left-to-right manner, the standard error stream would first be redirected to wherever the standard output stream goes (possibly to the console), and then the standard output stream would be redirected to a file. The standard error stream would not be redirected to that file.



            The visible effect of this would be that you get what's produced on standard error on the screen and what's produced on standard output in the file.



            utility 2>&1 | tee output.log


            Here, you redirect standard error to the same place as the standard output stream. This means that both streams will be piped to the tee utility as a single intermingled output stream, and that this standard output data will be saved to the given file by tee. The data would additionally be reproduced by tee in the console (this is what tee does, it duplicates data streams).



            Which ever one of these is used depends on what you'd like to achieve.



            Note that you would not be able to reproduce the effect of the second pipeline with just > (as in utility >output.log 2>&1, which would save both standard output and error in the file). You would need to use tee to get the data in the console as well as in the output file.




            Additional notes:



            The visible effect of the first command,



            utility 2>&1 >output.log 


            would be the same as



            utility >output.log


            I.e., the standard output goes to the file and standard error goes to the console.



            If a further processing step was added to the end of each of the above commands, there would be a big difference though:



            utility 2>&1 >output.log | more_stuff

            utility >output.log | more_stuff


            In the first pipeline, more_stuff would get what's originally the standard error stream from utility as its standard input data, while in the second pipeline, since it's only the resulting standard output stream that is ever sent across a pipe, the more_stuff part of the pipeline would get nothing to read on its standard input.






            share|improve this answer

























            • With the command "utility 2>&1 | tee output.log, do you mean to say that since 1 is being directed to tee, 2 is as well. Since tee duplicates the stream, the output is both displayed on the console as well as written to file? Hence the difference between utility 2>&1 > output.log and utility 2>&1 | tee output.log is tee in that it duplicates the stream. Would that be correct?

              – Motivated
              Jan 21 at 16:09











            • With the examples of utility 2>&1 > output.log | more_stuff and utility >ouput.log | more_stuff, is the difference that more_stuff` has the standard error output to the console as an input more_stuff? Since in the second example, there is no output to the the console, there is essentially no input to more_stuff? If yes, that isn't clear since the preceding paragraph you note that standard output goes to the file and standard error goes to the console.

              – Motivated
              Jan 21 at 16:17












            • @Motivated Your first comment seems correct to me, yes. As for the second comment: In the first command, more_stuff would receive what utility originally sent to its error stream (but which was redirected to the standard output). Not because it would end up on the console if more_stuff wasn't there, but because it's going to the standard output stream. In the second command, more_stuff receives nothing as there is no standard output from the left hand side of the pipeline. The error stream from utility would still end up on the console in the 2nd command.

              – Kusalananda
              Jan 21 at 18:31












            • Thanks. Do you mean that because the command utility > output.log | more_stuff does not result in an output in the standard output stream from a standard error point of view?

              – Motivated
              Jan 22 at 5:48











            • @Motivated Since the left hand side doesn't produce anything on standard output (it's redirected), no data will be sent over the pipe.

              – Kusalananda
              Jan 22 at 8:29


















            4














            The former outputs only to the file. The second outputs both to the file and to the screen.






            share|improve this answer






























              4














              The reason for 2>&1 | tee is to be able to capture both stdout and stderr to a log file and to see it on the screen at the same time. This could be done as >output.txt 2>&1 & tail -f as well, but you wouldn't know when the backgrounded command terminated - is the program terminated or is it running with no output. The 2>&1 | tee was a common idiom for programmers.






              share|improve this answer























              • Do you mean to say that 2>&1 > file.txt for example would not capture both stdout and stderr to file.txt?

                – Motivated
                Jan 21 at 7:28


















              -1














              Here is a post summarizing Unix output streams: http://www.devcodenote.com/2015/04/unix-output-streams.html



              A snippet from the post:



              There are 3 standard output streams:



              STDIN - Standard Input - Writes from an input device to the program
              STDOUT - Standard Output - Writes program output to screen unless specified otherwise.
              STDERR - Standard Error Output - Writes error messages. Also printed to the screen unless specified otherwise.





              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%2f20469%2fdifference-between-21-output-log-and-21-tee-output-log%23new-answer', 'question_page');

                );

                Post as a guest















                Required, but never shown

























                6 Answers
                6






                active

                oldest

                votes








                6 Answers
                6






                active

                oldest

                votes









                active

                oldest

                votes






                active

                oldest

                votes









                21














                Editorial note



                Please make sure to read the comments on this answer — derobert.




                Original answer



                2>&1 >output.log means first start sending all file handle 2 stuff (standard error) to file handle 1 (standard output) then send that to the file output.log. In other words, send standard error and standard output to the log file.



                2>&1 | tee output.log is the same with the 2>&1 bit, it combines standard output and standard error on to the standard output stream. It then pipes that through the tee program which will send its standard input to its standard output (like cat) and also to the file. So it combines the two streams (error and output), then outputs that to the terminal and the file.



                The bottom line is that the first sends stderr/stdout to the file, while the second sends it to both the file and standard output (which is probably the terminal unless you're inside another construct which has redirected standard output).



                I mention that last possibility because you can have stuff like:



                (echo hello | tee xyzzy.txt) >plugh.txt


                where nothing ends up on the terminal.






                share|improve this answer




















                • 13





                  -1 You have the syntax right, but not the semantics. Run cat /doesnotexist 2>&1 >output.txt - you will see see cat: /doesnotexist: No such file or directory displayed to the terminal and output.txt is an empty file. Order of precedence and closure are in play: 2>&1 (dup fd2 from the current fd1), then >output.txt (redirect fd1 to output.txt, not changing anything else). The reason that 2>&1 | is different is because of order of precedence: | before >.

                  – Arcege
                  Sep 10 '11 at 23:33






                • 5





                  This answer is fundamentally wrong in essentially every respect. Many of the answers below are better, but I think this one by Kusalananda is the clearest.

                  – Michael Homer
                  Jan 22 at 2:46






                • 1





                  @user14408: Should you ever make an account on Unix & Linux and claim this answer, please feel free to remove my editorial note once you've addressed the comments.

                  – derobert
                  Jan 22 at 19:01















                21














                Editorial note



                Please make sure to read the comments on this answer — derobert.




                Original answer



                2>&1 >output.log means first start sending all file handle 2 stuff (standard error) to file handle 1 (standard output) then send that to the file output.log. In other words, send standard error and standard output to the log file.



                2>&1 | tee output.log is the same with the 2>&1 bit, it combines standard output and standard error on to the standard output stream. It then pipes that through the tee program which will send its standard input to its standard output (like cat) and also to the file. So it combines the two streams (error and output), then outputs that to the terminal and the file.



                The bottom line is that the first sends stderr/stdout to the file, while the second sends it to both the file and standard output (which is probably the terminal unless you're inside another construct which has redirected standard output).



                I mention that last possibility because you can have stuff like:



                (echo hello | tee xyzzy.txt) >plugh.txt


                where nothing ends up on the terminal.






                share|improve this answer




















                • 13





                  -1 You have the syntax right, but not the semantics. Run cat /doesnotexist 2>&1 >output.txt - you will see see cat: /doesnotexist: No such file or directory displayed to the terminal and output.txt is an empty file. Order of precedence and closure are in play: 2>&1 (dup fd2 from the current fd1), then >output.txt (redirect fd1 to output.txt, not changing anything else). The reason that 2>&1 | is different is because of order of precedence: | before >.

                  – Arcege
                  Sep 10 '11 at 23:33






                • 5





                  This answer is fundamentally wrong in essentially every respect. Many of the answers below are better, but I think this one by Kusalananda is the clearest.

                  – Michael Homer
                  Jan 22 at 2:46






                • 1





                  @user14408: Should you ever make an account on Unix & Linux and claim this answer, please feel free to remove my editorial note once you've addressed the comments.

                  – derobert
                  Jan 22 at 19:01













                21












                21








                21







                Editorial note



                Please make sure to read the comments on this answer — derobert.




                Original answer



                2>&1 >output.log means first start sending all file handle 2 stuff (standard error) to file handle 1 (standard output) then send that to the file output.log. In other words, send standard error and standard output to the log file.



                2>&1 | tee output.log is the same with the 2>&1 bit, it combines standard output and standard error on to the standard output stream. It then pipes that through the tee program which will send its standard input to its standard output (like cat) and also to the file. So it combines the two streams (error and output), then outputs that to the terminal and the file.



                The bottom line is that the first sends stderr/stdout to the file, while the second sends it to both the file and standard output (which is probably the terminal unless you're inside another construct which has redirected standard output).



                I mention that last possibility because you can have stuff like:



                (echo hello | tee xyzzy.txt) >plugh.txt


                where nothing ends up on the terminal.






                share|improve this answer















                Editorial note



                Please make sure to read the comments on this answer — derobert.




                Original answer



                2>&1 >output.log means first start sending all file handle 2 stuff (standard error) to file handle 1 (standard output) then send that to the file output.log. In other words, send standard error and standard output to the log file.



                2>&1 | tee output.log is the same with the 2>&1 bit, it combines standard output and standard error on to the standard output stream. It then pipes that through the tee program which will send its standard input to its standard output (like cat) and also to the file. So it combines the two streams (error and output), then outputs that to the terminal and the file.



                The bottom line is that the first sends stderr/stdout to the file, while the second sends it to both the file and standard output (which is probably the terminal unless you're inside another construct which has redirected standard output).



                I mention that last possibility because you can have stuff like:



                (echo hello | tee xyzzy.txt) >plugh.txt


                where nothing ends up on the terminal.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Jan 22 at 18:56









                derobert

                73.4k8156211




                73.4k8156211










                answered Sep 10 '11 at 1:03







                user14408














                • 13





                  -1 You have the syntax right, but not the semantics. Run cat /doesnotexist 2>&1 >output.txt - you will see see cat: /doesnotexist: No such file or directory displayed to the terminal and output.txt is an empty file. Order of precedence and closure are in play: 2>&1 (dup fd2 from the current fd1), then >output.txt (redirect fd1 to output.txt, not changing anything else). The reason that 2>&1 | is different is because of order of precedence: | before >.

                  – Arcege
                  Sep 10 '11 at 23:33






                • 5





                  This answer is fundamentally wrong in essentially every respect. Many of the answers below are better, but I think this one by Kusalananda is the clearest.

                  – Michael Homer
                  Jan 22 at 2:46






                • 1





                  @user14408: Should you ever make an account on Unix & Linux and claim this answer, please feel free to remove my editorial note once you've addressed the comments.

                  – derobert
                  Jan 22 at 19:01












                • 13





                  -1 You have the syntax right, but not the semantics. Run cat /doesnotexist 2>&1 >output.txt - you will see see cat: /doesnotexist: No such file or directory displayed to the terminal and output.txt is an empty file. Order of precedence and closure are in play: 2>&1 (dup fd2 from the current fd1), then >output.txt (redirect fd1 to output.txt, not changing anything else). The reason that 2>&1 | is different is because of order of precedence: | before >.

                  – Arcege
                  Sep 10 '11 at 23:33






                • 5





                  This answer is fundamentally wrong in essentially every respect. Many of the answers below are better, but I think this one by Kusalananda is the clearest.

                  – Michael Homer
                  Jan 22 at 2:46






                • 1





                  @user14408: Should you ever make an account on Unix & Linux and claim this answer, please feel free to remove my editorial note once you've addressed the comments.

                  – derobert
                  Jan 22 at 19:01







                13




                13





                -1 You have the syntax right, but not the semantics. Run cat /doesnotexist 2>&1 >output.txt - you will see see cat: /doesnotexist: No such file or directory displayed to the terminal and output.txt is an empty file. Order of precedence and closure are in play: 2>&1 (dup fd2 from the current fd1), then >output.txt (redirect fd1 to output.txt, not changing anything else). The reason that 2>&1 | is different is because of order of precedence: | before >.

                – Arcege
                Sep 10 '11 at 23:33





                -1 You have the syntax right, but not the semantics. Run cat /doesnotexist 2>&1 >output.txt - you will see see cat: /doesnotexist: No such file or directory displayed to the terminal and output.txt is an empty file. Order of precedence and closure are in play: 2>&1 (dup fd2 from the current fd1), then >output.txt (redirect fd1 to output.txt, not changing anything else). The reason that 2>&1 | is different is because of order of precedence: | before >.

                – Arcege
                Sep 10 '11 at 23:33




                5




                5





                This answer is fundamentally wrong in essentially every respect. Many of the answers below are better, but I think this one by Kusalananda is the clearest.

                – Michael Homer
                Jan 22 at 2:46





                This answer is fundamentally wrong in essentially every respect. Many of the answers below are better, but I think this one by Kusalananda is the clearest.

                – Michael Homer
                Jan 22 at 2:46




                1




                1





                @user14408: Should you ever make an account on Unix & Linux and claim this answer, please feel free to remove my editorial note once you've addressed the comments.

                – derobert
                Jan 22 at 19:01





                @user14408: Should you ever make an account on Unix & Linux and claim this answer, please feel free to remove my editorial note once you've addressed the comments.

                – derobert
                Jan 22 at 19:01













                8














                First command will do the another task:



                After



                2>&1 > output.log 


                the old STDOUT will be saved (copied) in STDERR and then STDOUT will be redirected to file.



                So, stdout will go to file and stderr will go to console.



                And in



                 2>&1 | tee output.log


                both streams will be redirected to tee. Tee will duplicate any input to its stdout (the console in your case) and to file (output.log).



                And there is another form of first:



                 > output.log 2>&1


                this will redirect both STDOUT and STDERR to the file.






                share|improve this answer



























                  8














                  First command will do the another task:



                  After



                  2>&1 > output.log 


                  the old STDOUT will be saved (copied) in STDERR and then STDOUT will be redirected to file.



                  So, stdout will go to file and stderr will go to console.



                  And in



                   2>&1 | tee output.log


                  both streams will be redirected to tee. Tee will duplicate any input to its stdout (the console in your case) and to file (output.log).



                  And there is another form of first:



                   > output.log 2>&1


                  this will redirect both STDOUT and STDERR to the file.






                  share|improve this answer

























                    8












                    8








                    8







                    First command will do the another task:



                    After



                    2>&1 > output.log 


                    the old STDOUT will be saved (copied) in STDERR and then STDOUT will be redirected to file.



                    So, stdout will go to file and stderr will go to console.



                    And in



                     2>&1 | tee output.log


                    both streams will be redirected to tee. Tee will duplicate any input to its stdout (the console in your case) and to file (output.log).



                    And there is another form of first:



                     > output.log 2>&1


                    this will redirect both STDOUT and STDERR to the file.






                    share|improve this answer













                    First command will do the another task:



                    After



                    2>&1 > output.log 


                    the old STDOUT will be saved (copied) in STDERR and then STDOUT will be redirected to file.



                    So, stdout will go to file and stderr will go to console.



                    And in



                     2>&1 | tee output.log


                    both streams will be redirected to tee. Tee will duplicate any input to its stdout (the console in your case) and to file (output.log).



                    And there is another form of first:



                     > output.log 2>&1


                    this will redirect both STDOUT and STDERR to the file.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Sep 10 '11 at 0:53









                    osgxosgx

                    690610




                    690610





















                        7














                        Looking at the two commands separately:



                        utility 2>&1 >output.log 


                        Here, since redirections are processed in a left-to-right manner, the standard error stream would first be redirected to wherever the standard output stream goes (possibly to the console), and then the standard output stream would be redirected to a file. The standard error stream would not be redirected to that file.



                        The visible effect of this would be that you get what's produced on standard error on the screen and what's produced on standard output in the file.



                        utility 2>&1 | tee output.log


                        Here, you redirect standard error to the same place as the standard output stream. This means that both streams will be piped to the tee utility as a single intermingled output stream, and that this standard output data will be saved to the given file by tee. The data would additionally be reproduced by tee in the console (this is what tee does, it duplicates data streams).



                        Which ever one of these is used depends on what you'd like to achieve.



                        Note that you would not be able to reproduce the effect of the second pipeline with just > (as in utility >output.log 2>&1, which would save both standard output and error in the file). You would need to use tee to get the data in the console as well as in the output file.




                        Additional notes:



                        The visible effect of the first command,



                        utility 2>&1 >output.log 


                        would be the same as



                        utility >output.log


                        I.e., the standard output goes to the file and standard error goes to the console.



                        If a further processing step was added to the end of each of the above commands, there would be a big difference though:



                        utility 2>&1 >output.log | more_stuff

                        utility >output.log | more_stuff


                        In the first pipeline, more_stuff would get what's originally the standard error stream from utility as its standard input data, while in the second pipeline, since it's only the resulting standard output stream that is ever sent across a pipe, the more_stuff part of the pipeline would get nothing to read on its standard input.






                        share|improve this answer

























                        • With the command "utility 2>&1 | tee output.log, do you mean to say that since 1 is being directed to tee, 2 is as well. Since tee duplicates the stream, the output is both displayed on the console as well as written to file? Hence the difference between utility 2>&1 > output.log and utility 2>&1 | tee output.log is tee in that it duplicates the stream. Would that be correct?

                          – Motivated
                          Jan 21 at 16:09











                        • With the examples of utility 2>&1 > output.log | more_stuff and utility >ouput.log | more_stuff, is the difference that more_stuff` has the standard error output to the console as an input more_stuff? Since in the second example, there is no output to the the console, there is essentially no input to more_stuff? If yes, that isn't clear since the preceding paragraph you note that standard output goes to the file and standard error goes to the console.

                          – Motivated
                          Jan 21 at 16:17












                        • @Motivated Your first comment seems correct to me, yes. As for the second comment: In the first command, more_stuff would receive what utility originally sent to its error stream (but which was redirected to the standard output). Not because it would end up on the console if more_stuff wasn't there, but because it's going to the standard output stream. In the second command, more_stuff receives nothing as there is no standard output from the left hand side of the pipeline. The error stream from utility would still end up on the console in the 2nd command.

                          – Kusalananda
                          Jan 21 at 18:31












                        • Thanks. Do you mean that because the command utility > output.log | more_stuff does not result in an output in the standard output stream from a standard error point of view?

                          – Motivated
                          Jan 22 at 5:48











                        • @Motivated Since the left hand side doesn't produce anything on standard output (it's redirected), no data will be sent over the pipe.

                          – Kusalananda
                          Jan 22 at 8:29















                        7














                        Looking at the two commands separately:



                        utility 2>&1 >output.log 


                        Here, since redirections are processed in a left-to-right manner, the standard error stream would first be redirected to wherever the standard output stream goes (possibly to the console), and then the standard output stream would be redirected to a file. The standard error stream would not be redirected to that file.



                        The visible effect of this would be that you get what's produced on standard error on the screen and what's produced on standard output in the file.



                        utility 2>&1 | tee output.log


                        Here, you redirect standard error to the same place as the standard output stream. This means that both streams will be piped to the tee utility as a single intermingled output stream, and that this standard output data will be saved to the given file by tee. The data would additionally be reproduced by tee in the console (this is what tee does, it duplicates data streams).



                        Which ever one of these is used depends on what you'd like to achieve.



                        Note that you would not be able to reproduce the effect of the second pipeline with just > (as in utility >output.log 2>&1, which would save both standard output and error in the file). You would need to use tee to get the data in the console as well as in the output file.




                        Additional notes:



                        The visible effect of the first command,



                        utility 2>&1 >output.log 


                        would be the same as



                        utility >output.log


                        I.e., the standard output goes to the file and standard error goes to the console.



                        If a further processing step was added to the end of each of the above commands, there would be a big difference though:



                        utility 2>&1 >output.log | more_stuff

                        utility >output.log | more_stuff


                        In the first pipeline, more_stuff would get what's originally the standard error stream from utility as its standard input data, while in the second pipeline, since it's only the resulting standard output stream that is ever sent across a pipe, the more_stuff part of the pipeline would get nothing to read on its standard input.






                        share|improve this answer

























                        • With the command "utility 2>&1 | tee output.log, do you mean to say that since 1 is being directed to tee, 2 is as well. Since tee duplicates the stream, the output is both displayed on the console as well as written to file? Hence the difference between utility 2>&1 > output.log and utility 2>&1 | tee output.log is tee in that it duplicates the stream. Would that be correct?

                          – Motivated
                          Jan 21 at 16:09











                        • With the examples of utility 2>&1 > output.log | more_stuff and utility >ouput.log | more_stuff, is the difference that more_stuff` has the standard error output to the console as an input more_stuff? Since in the second example, there is no output to the the console, there is essentially no input to more_stuff? If yes, that isn't clear since the preceding paragraph you note that standard output goes to the file and standard error goes to the console.

                          – Motivated
                          Jan 21 at 16:17












                        • @Motivated Your first comment seems correct to me, yes. As for the second comment: In the first command, more_stuff would receive what utility originally sent to its error stream (but which was redirected to the standard output). Not because it would end up on the console if more_stuff wasn't there, but because it's going to the standard output stream. In the second command, more_stuff receives nothing as there is no standard output from the left hand side of the pipeline. The error stream from utility would still end up on the console in the 2nd command.

                          – Kusalananda
                          Jan 21 at 18:31












                        • Thanks. Do you mean that because the command utility > output.log | more_stuff does not result in an output in the standard output stream from a standard error point of view?

                          – Motivated
                          Jan 22 at 5:48











                        • @Motivated Since the left hand side doesn't produce anything on standard output (it's redirected), no data will be sent over the pipe.

                          – Kusalananda
                          Jan 22 at 8:29













                        7












                        7








                        7







                        Looking at the two commands separately:



                        utility 2>&1 >output.log 


                        Here, since redirections are processed in a left-to-right manner, the standard error stream would first be redirected to wherever the standard output stream goes (possibly to the console), and then the standard output stream would be redirected to a file. The standard error stream would not be redirected to that file.



                        The visible effect of this would be that you get what's produced on standard error on the screen and what's produced on standard output in the file.



                        utility 2>&1 | tee output.log


                        Here, you redirect standard error to the same place as the standard output stream. This means that both streams will be piped to the tee utility as a single intermingled output stream, and that this standard output data will be saved to the given file by tee. The data would additionally be reproduced by tee in the console (this is what tee does, it duplicates data streams).



                        Which ever one of these is used depends on what you'd like to achieve.



                        Note that you would not be able to reproduce the effect of the second pipeline with just > (as in utility >output.log 2>&1, which would save both standard output and error in the file). You would need to use tee to get the data in the console as well as in the output file.




                        Additional notes:



                        The visible effect of the first command,



                        utility 2>&1 >output.log 


                        would be the same as



                        utility >output.log


                        I.e., the standard output goes to the file and standard error goes to the console.



                        If a further processing step was added to the end of each of the above commands, there would be a big difference though:



                        utility 2>&1 >output.log | more_stuff

                        utility >output.log | more_stuff


                        In the first pipeline, more_stuff would get what's originally the standard error stream from utility as its standard input data, while in the second pipeline, since it's only the resulting standard output stream that is ever sent across a pipe, the more_stuff part of the pipeline would get nothing to read on its standard input.






                        share|improve this answer















                        Looking at the two commands separately:



                        utility 2>&1 >output.log 


                        Here, since redirections are processed in a left-to-right manner, the standard error stream would first be redirected to wherever the standard output stream goes (possibly to the console), and then the standard output stream would be redirected to a file. The standard error stream would not be redirected to that file.



                        The visible effect of this would be that you get what's produced on standard error on the screen and what's produced on standard output in the file.



                        utility 2>&1 | tee output.log


                        Here, you redirect standard error to the same place as the standard output stream. This means that both streams will be piped to the tee utility as a single intermingled output stream, and that this standard output data will be saved to the given file by tee. The data would additionally be reproduced by tee in the console (this is what tee does, it duplicates data streams).



                        Which ever one of these is used depends on what you'd like to achieve.



                        Note that you would not be able to reproduce the effect of the second pipeline with just > (as in utility >output.log 2>&1, which would save both standard output and error in the file). You would need to use tee to get the data in the console as well as in the output file.




                        Additional notes:



                        The visible effect of the first command,



                        utility 2>&1 >output.log 


                        would be the same as



                        utility >output.log


                        I.e., the standard output goes to the file and standard error goes to the console.



                        If a further processing step was added to the end of each of the above commands, there would be a big difference though:



                        utility 2>&1 >output.log | more_stuff

                        utility >output.log | more_stuff


                        In the first pipeline, more_stuff would get what's originally the standard error stream from utility as its standard input data, while in the second pipeline, since it's only the resulting standard output stream that is ever sent across a pipe, the more_stuff part of the pipeline would get nothing to read on its standard input.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Jan 21 at 9:52

























                        answered Jan 21 at 8:40









                        KusalanandaKusalananda

                        128k16242399




                        128k16242399












                        • With the command "utility 2>&1 | tee output.log, do you mean to say that since 1 is being directed to tee, 2 is as well. Since tee duplicates the stream, the output is both displayed on the console as well as written to file? Hence the difference between utility 2>&1 > output.log and utility 2>&1 | tee output.log is tee in that it duplicates the stream. Would that be correct?

                          – Motivated
                          Jan 21 at 16:09











                        • With the examples of utility 2>&1 > output.log | more_stuff and utility >ouput.log | more_stuff, is the difference that more_stuff` has the standard error output to the console as an input more_stuff? Since in the second example, there is no output to the the console, there is essentially no input to more_stuff? If yes, that isn't clear since the preceding paragraph you note that standard output goes to the file and standard error goes to the console.

                          – Motivated
                          Jan 21 at 16:17












                        • @Motivated Your first comment seems correct to me, yes. As for the second comment: In the first command, more_stuff would receive what utility originally sent to its error stream (but which was redirected to the standard output). Not because it would end up on the console if more_stuff wasn't there, but because it's going to the standard output stream. In the second command, more_stuff receives nothing as there is no standard output from the left hand side of the pipeline. The error stream from utility would still end up on the console in the 2nd command.

                          – Kusalananda
                          Jan 21 at 18:31












                        • Thanks. Do you mean that because the command utility > output.log | more_stuff does not result in an output in the standard output stream from a standard error point of view?

                          – Motivated
                          Jan 22 at 5:48











                        • @Motivated Since the left hand side doesn't produce anything on standard output (it's redirected), no data will be sent over the pipe.

                          – Kusalananda
                          Jan 22 at 8:29

















                        • With the command "utility 2>&1 | tee output.log, do you mean to say that since 1 is being directed to tee, 2 is as well. Since tee duplicates the stream, the output is both displayed on the console as well as written to file? Hence the difference between utility 2>&1 > output.log and utility 2>&1 | tee output.log is tee in that it duplicates the stream. Would that be correct?

                          – Motivated
                          Jan 21 at 16:09











                        • With the examples of utility 2>&1 > output.log | more_stuff and utility >ouput.log | more_stuff, is the difference that more_stuff` has the standard error output to the console as an input more_stuff? Since in the second example, there is no output to the the console, there is essentially no input to more_stuff? If yes, that isn't clear since the preceding paragraph you note that standard output goes to the file and standard error goes to the console.

                          – Motivated
                          Jan 21 at 16:17












                        • @Motivated Your first comment seems correct to me, yes. As for the second comment: In the first command, more_stuff would receive what utility originally sent to its error stream (but which was redirected to the standard output). Not because it would end up on the console if more_stuff wasn't there, but because it's going to the standard output stream. In the second command, more_stuff receives nothing as there is no standard output from the left hand side of the pipeline. The error stream from utility would still end up on the console in the 2nd command.

                          – Kusalananda
                          Jan 21 at 18:31












                        • Thanks. Do you mean that because the command utility > output.log | more_stuff does not result in an output in the standard output stream from a standard error point of view?

                          – Motivated
                          Jan 22 at 5:48











                        • @Motivated Since the left hand side doesn't produce anything on standard output (it's redirected), no data will be sent over the pipe.

                          – Kusalananda
                          Jan 22 at 8:29
















                        With the command "utility 2>&1 | tee output.log, do you mean to say that since 1 is being directed to tee, 2 is as well. Since tee duplicates the stream, the output is both displayed on the console as well as written to file? Hence the difference between utility 2>&1 > output.log and utility 2>&1 | tee output.log is tee in that it duplicates the stream. Would that be correct?

                        – Motivated
                        Jan 21 at 16:09





                        With the command "utility 2>&1 | tee output.log, do you mean to say that since 1 is being directed to tee, 2 is as well. Since tee duplicates the stream, the output is both displayed on the console as well as written to file? Hence the difference between utility 2>&1 > output.log and utility 2>&1 | tee output.log is tee in that it duplicates the stream. Would that be correct?

                        – Motivated
                        Jan 21 at 16:09













                        With the examples of utility 2>&1 > output.log | more_stuff and utility >ouput.log | more_stuff, is the difference that more_stuff` has the standard error output to the console as an input more_stuff? Since in the second example, there is no output to the the console, there is essentially no input to more_stuff? If yes, that isn't clear since the preceding paragraph you note that standard output goes to the file and standard error goes to the console.

                        – Motivated
                        Jan 21 at 16:17






                        With the examples of utility 2>&1 > output.log | more_stuff and utility >ouput.log | more_stuff, is the difference that more_stuff` has the standard error output to the console as an input more_stuff? Since in the second example, there is no output to the the console, there is essentially no input to more_stuff? If yes, that isn't clear since the preceding paragraph you note that standard output goes to the file and standard error goes to the console.

                        – Motivated
                        Jan 21 at 16:17














                        @Motivated Your first comment seems correct to me, yes. As for the second comment: In the first command, more_stuff would receive what utility originally sent to its error stream (but which was redirected to the standard output). Not because it would end up on the console if more_stuff wasn't there, but because it's going to the standard output stream. In the second command, more_stuff receives nothing as there is no standard output from the left hand side of the pipeline. The error stream from utility would still end up on the console in the 2nd command.

                        – Kusalananda
                        Jan 21 at 18:31






                        @Motivated Your first comment seems correct to me, yes. As for the second comment: In the first command, more_stuff would receive what utility originally sent to its error stream (but which was redirected to the standard output). Not because it would end up on the console if more_stuff wasn't there, but because it's going to the standard output stream. In the second command, more_stuff receives nothing as there is no standard output from the left hand side of the pipeline. The error stream from utility would still end up on the console in the 2nd command.

                        – Kusalananda
                        Jan 21 at 18:31














                        Thanks. Do you mean that because the command utility > output.log | more_stuff does not result in an output in the standard output stream from a standard error point of view?

                        – Motivated
                        Jan 22 at 5:48





                        Thanks. Do you mean that because the command utility > output.log | more_stuff does not result in an output in the standard output stream from a standard error point of view?

                        – Motivated
                        Jan 22 at 5:48













                        @Motivated Since the left hand side doesn't produce anything on standard output (it's redirected), no data will be sent over the pipe.

                        – Kusalananda
                        Jan 22 at 8:29





                        @Motivated Since the left hand side doesn't produce anything on standard output (it's redirected), no data will be sent over the pipe.

                        – Kusalananda
                        Jan 22 at 8:29











                        4














                        The former outputs only to the file. The second outputs both to the file and to the screen.






                        share|improve this answer



























                          4














                          The former outputs only to the file. The second outputs both to the file and to the screen.






                          share|improve this answer

























                            4












                            4








                            4







                            The former outputs only to the file. The second outputs both to the file and to the screen.






                            share|improve this answer













                            The former outputs only to the file. The second outputs both to the file and to the screen.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Sep 10 '11 at 0:52







                            André Caron




























                                4














                                The reason for 2>&1 | tee is to be able to capture both stdout and stderr to a log file and to see it on the screen at the same time. This could be done as >output.txt 2>&1 & tail -f as well, but you wouldn't know when the backgrounded command terminated - is the program terminated or is it running with no output. The 2>&1 | tee was a common idiom for programmers.






                                share|improve this answer























                                • Do you mean to say that 2>&1 > file.txt for example would not capture both stdout and stderr to file.txt?

                                  – Motivated
                                  Jan 21 at 7:28















                                4














                                The reason for 2>&1 | tee is to be able to capture both stdout and stderr to a log file and to see it on the screen at the same time. This could be done as >output.txt 2>&1 & tail -f as well, but you wouldn't know when the backgrounded command terminated - is the program terminated or is it running with no output. The 2>&1 | tee was a common idiom for programmers.






                                share|improve this answer























                                • Do you mean to say that 2>&1 > file.txt for example would not capture both stdout and stderr to file.txt?

                                  – Motivated
                                  Jan 21 at 7:28













                                4












                                4








                                4







                                The reason for 2>&1 | tee is to be able to capture both stdout and stderr to a log file and to see it on the screen at the same time. This could be done as >output.txt 2>&1 & tail -f as well, but you wouldn't know when the backgrounded command terminated - is the program terminated or is it running with no output. The 2>&1 | tee was a common idiom for programmers.






                                share|improve this answer













                                The reason for 2>&1 | tee is to be able to capture both stdout and stderr to a log file and to see it on the screen at the same time. This could be done as >output.txt 2>&1 & tail -f as well, but you wouldn't know when the backgrounded command terminated - is the program terminated or is it running with no output. The 2>&1 | tee was a common idiom for programmers.







                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                answered Sep 10 '11 at 23:51









                                ArcegeArcege

                                17.1k44257




                                17.1k44257












                                • Do you mean to say that 2>&1 > file.txt for example would not capture both stdout and stderr to file.txt?

                                  – Motivated
                                  Jan 21 at 7:28

















                                • Do you mean to say that 2>&1 > file.txt for example would not capture both stdout and stderr to file.txt?

                                  – Motivated
                                  Jan 21 at 7:28
















                                Do you mean to say that 2>&1 > file.txt for example would not capture both stdout and stderr to file.txt?

                                – Motivated
                                Jan 21 at 7:28





                                Do you mean to say that 2>&1 > file.txt for example would not capture both stdout and stderr to file.txt?

                                – Motivated
                                Jan 21 at 7:28











                                -1














                                Here is a post summarizing Unix output streams: http://www.devcodenote.com/2015/04/unix-output-streams.html



                                A snippet from the post:



                                There are 3 standard output streams:



                                STDIN - Standard Input - Writes from an input device to the program
                                STDOUT - Standard Output - Writes program output to screen unless specified otherwise.
                                STDERR - Standard Error Output - Writes error messages. Also printed to the screen unless specified otherwise.





                                share|improve this answer



























                                  -1














                                  Here is a post summarizing Unix output streams: http://www.devcodenote.com/2015/04/unix-output-streams.html



                                  A snippet from the post:



                                  There are 3 standard output streams:



                                  STDIN - Standard Input - Writes from an input device to the program
                                  STDOUT - Standard Output - Writes program output to screen unless specified otherwise.
                                  STDERR - Standard Error Output - Writes error messages. Also printed to the screen unless specified otherwise.





                                  share|improve this answer

























                                    -1












                                    -1








                                    -1







                                    Here is a post summarizing Unix output streams: http://www.devcodenote.com/2015/04/unix-output-streams.html



                                    A snippet from the post:



                                    There are 3 standard output streams:



                                    STDIN - Standard Input - Writes from an input device to the program
                                    STDOUT - Standard Output - Writes program output to screen unless specified otherwise.
                                    STDERR - Standard Error Output - Writes error messages. Also printed to the screen unless specified otherwise.





                                    share|improve this answer













                                    Here is a post summarizing Unix output streams: http://www.devcodenote.com/2015/04/unix-output-streams.html



                                    A snippet from the post:



                                    There are 3 standard output streams:



                                    STDIN - Standard Input - Writes from an input device to the program
                                    STDOUT - Standard Output - Writes program output to screen unless specified otherwise.
                                    STDERR - Standard Error Output - Writes error messages. Also printed to the screen unless specified otherwise.






                                    share|improve this answer












                                    share|improve this answer



                                    share|improve this answer










                                    answered Apr 17 '15 at 3:41









                                    Abhishek JainAbhishek Jain

                                    991




                                    991



























                                        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%2f20469%2fdifference-between-21-output-log-and-21-tee-output-log%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

                                        How to check contact read email or not when send email to Individual?

                                        Bahrain

                                        Postfix configuration issue with fips on centos 7; mailgun relay