Understanding piped commands in GNU/Linux Announcing the arrival of Valued Associate #679:...

An isoperimetric-type inequality inside a cube

Are there any irrational/transcendental numbers for which the distribution of decimal digits is not uniform?

Order between one to one functions and their inverses

Is there a verb for listening stealthily?

What are some likely causes to domain member PC losing contact to domain controller?

Why not use the yoke to control yaw, as well as pitch and roll?

Any stored/leased 737s that could substitute for grounded MAXs?

First paper to introduce the "principal-agent problem"

Besides transaction validation, are there any other uses of the Script language in Bitcoin

Found this skink in my tomato plant bucket. Is he trapped? Or could he leave if he wanted?

Determine whether an integer is a palindrome

Why are current probes so expensive?

How much damage would a cupful of neutron star matter do to the Earth?

When to apply negative sign when number is squared

How to make an animal which can only breed for a certain number of generations?

Why can't fire hurt Daenerys but it did to Jon Snow in season 1?

How does the body cool itself in a stillsuit?

Did any compiler fully use 80-bit floating point?

Why did Bronn offer to be Tyrion Lannister's champion in trial by combat?

How to ask rejected full-time candidates to apply to teach individual courses?

2018 MacBook Pro won't let me install macOS High Sierra 10.13 from USB installer

NIntegrate on a solution of a matrix ODE

What was the last profitable war?

Is it OK to use the testing sample to compare algorithms?



Understanding piped commands in GNU/Linux



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
2019 Community Moderator Election Results
Why I closed the “Why is Kali so hard” questionHow big is the pipe buffer?In what order do piped commands run?In what order do piped commands run?Redirecting stdin with stdout to fileUnderstanding behavior of subshell and stdout with pipeWhy do some commands not read from their standard input?“Leaky” pipes in linuxCan writing to stdout place backpressure on a process?How can pipe producer tell pipe consumer it has reached 'End of File'?" (un-named-pipe, not named-pipe)Take a command that modifies a file inline and make it accept stdin/stdoutPipeline running in parallel through creating multiple subshellsHow shell delivers user's input to program and shows program's output?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







7















I have two simple C programs: A and B. A would run first, then B gets the stdout of A and uses it as its stdin. Assume I am using a GNU/Linux operating system and the simplest possible way to do this would be:



./A | ./B


If I had to describe this command I would say that it is a command that takes input from a producer (A) and writes to a consumer (B). Is that a correct description? Is there anything that I am missing?










share|improve this question









New contributor




nihulus is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • Related: In what order do piped commands run?

    – G-Man
    2 hours ago


















7















I have two simple C programs: A and B. A would run first, then B gets the stdout of A and uses it as its stdin. Assume I am using a GNU/Linux operating system and the simplest possible way to do this would be:



./A | ./B


If I had to describe this command I would say that it is a command that takes input from a producer (A) and writes to a consumer (B). Is that a correct description? Is there anything that I am missing?










share|improve this question









New contributor




nihulus is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • Related: In what order do piped commands run?

    – G-Man
    2 hours ago














7












7








7


2






I have two simple C programs: A and B. A would run first, then B gets the stdout of A and uses it as its stdin. Assume I am using a GNU/Linux operating system and the simplest possible way to do this would be:



./A | ./B


If I had to describe this command I would say that it is a command that takes input from a producer (A) and writes to a consumer (B). Is that a correct description? Is there anything that I am missing?










share|improve this question









New contributor




nihulus is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












I have two simple C programs: A and B. A would run first, then B gets the stdout of A and uses it as its stdin. Assume I am using a GNU/Linux operating system and the simplest possible way to do this would be:



./A | ./B


If I had to describe this command I would say that it is a command that takes input from a producer (A) and writes to a consumer (B). Is that a correct description? Is there anything that I am missing?







pipe c






share|improve this question









New contributor




nihulus is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




nihulus is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 38 mins ago









JL2210

1033




1033






New contributor




nihulus is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 11 hours ago









nihulusnihulus

1413




1413




New contributor




nihulus is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





nihulus is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






nihulus is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.













  • Related: In what order do piped commands run?

    – G-Man
    2 hours ago



















  • Related: In what order do piped commands run?

    – G-Man
    2 hours ago

















Related: In what order do piped commands run?

– G-Man
2 hours ago





Related: In what order do piped commands run?

– G-Man
2 hours ago










2 Answers
2






active

oldest

votes


















14














The only thing about your question that stands out as wrong is that you say




A would run first, then B gets the stdout of A




In fact, both programs would be started at pretty much the same time. If there's no input for B when it tries to read, it will block until there is input to read. Likewise, if there's nobody reading the output from A, its writes will block until its output is read (some of it will be buffered by the pipe).



The only thing synchronising the processes that take part in a pipeline is the I/O, i.e. the reading and writing. If no writing or reading happens, then the two processes will run totally independent of each other. If one ignores the reading or writing of the other, the ignored process will block and eventually be killed by a SIGPIPE signal (if writing) or get an end-of-file condition on its standard input stream (if reading) when the other process terminates.



The idiomatic way to describe A | B is that it's a pipeline containing two programs. The output produced on standard output from the first program is available to be read on the standard input by the second ("[the output of] A is piped into B"). The shell does the required plumbing to allow this to happen.



If you want to use the words "consumer" and "producer", I suppose that's ok too.



The fact that these are programs written in C is not relevant. The fact that this is Linux, macOS, OpenBSD or AIX is not relevant.






share|improve this answer


























  • Actually, we can think of having A and B running in parallel as an optimization. The command is equivalent to ./A > tmp_file && ./B < tmp_file, which first save the output of A to tmp_file and then give it as an input to B. This information is taken from: okmij.org/ftp/Computation/monadic-shell.html (I change the command slightly)

    – Alex Vong
    7 hours ago








  • 1





    Writing to a temporary file was used in DOS, as that didn't support multiple processes.

    – CSM
    5 hours ago






  • 1





    @AlexVong Note though that your example with a temporary file is not exactly equivalent. A program may choose to seek though the contents of a file, but data coming off a pipe is not seekable. A better examlp would be to use mkfifo to create a named pipe, then start B in the background reading from the pipe, and then A writing to it. This is nit-picking though, as the effect would be the same.

    – Kusalananda
    5 hours ago






  • 1





    @AlexVong The simplifications made in that article divorce it from real pipelines; the parallel execution is truly semantic, not an optimisation. It's a reasonable lies-to-children explanation of monadic evaluation or composition for someone who's seen shell pipelines, but it's not valid in the other direction. Kusalananda's fifo version is closer, but the error propagation parts of the model are genuinely important and not replicable. (all of which I say as someone who is very on the "shell pipelines are just function composition" train)

    – Michael Homer
    2 hours ago








  • 1





    @AlexVong No, that's completely off track. That isn't able to explain even something simple like yes | sed 10q

    – Uncle Billy
    1 hour ago





















0














The term usually used in documentation is "pipeline" , which consists of one or more commands, see POSIX definition So technically speaking, that's two commands you have there, two subprocesses for the shell (either fork()+exec()'ed external commands or subshells )



As for producer-consumer part, the pipeline can be described by that pattern, since:




  • Producer and Consumer share fixed-size buffer, and at least on Linux and MacOS X, there's fixed size for pipeline buffer

  • Producer and Consumer are loosely-coupled, commands in pipeline don't know of each other's existence ( unless they are actively checking /proc/<pid>/fd directory ).

  • Producers write to stdout and consumers read stdin as if they were a single command being executed, aka they can exist without each other.


The difference I see here is that unlike Producer-Consumer in other languges, shell commands use buffering and they write stdout once buffer is filled, but there's no mention that Producer-Consumer has to follow that rule - only wait when queue is filled or discard data (which is something else that pipeline doesn't do).






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
    });


    }
    });






    nihulus is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f513657%2funderstanding-piped-commands-in-gnu-linux%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    14














    The only thing about your question that stands out as wrong is that you say




    A would run first, then B gets the stdout of A




    In fact, both programs would be started at pretty much the same time. If there's no input for B when it tries to read, it will block until there is input to read. Likewise, if there's nobody reading the output from A, its writes will block until its output is read (some of it will be buffered by the pipe).



    The only thing synchronising the processes that take part in a pipeline is the I/O, i.e. the reading and writing. If no writing or reading happens, then the two processes will run totally independent of each other. If one ignores the reading or writing of the other, the ignored process will block and eventually be killed by a SIGPIPE signal (if writing) or get an end-of-file condition on its standard input stream (if reading) when the other process terminates.



    The idiomatic way to describe A | B is that it's a pipeline containing two programs. The output produced on standard output from the first program is available to be read on the standard input by the second ("[the output of] A is piped into B"). The shell does the required plumbing to allow this to happen.



    If you want to use the words "consumer" and "producer", I suppose that's ok too.



    The fact that these are programs written in C is not relevant. The fact that this is Linux, macOS, OpenBSD or AIX is not relevant.






    share|improve this answer


























    • Actually, we can think of having A and B running in parallel as an optimization. The command is equivalent to ./A > tmp_file && ./B < tmp_file, which first save the output of A to tmp_file and then give it as an input to B. This information is taken from: okmij.org/ftp/Computation/monadic-shell.html (I change the command slightly)

      – Alex Vong
      7 hours ago








    • 1





      Writing to a temporary file was used in DOS, as that didn't support multiple processes.

      – CSM
      5 hours ago






    • 1





      @AlexVong Note though that your example with a temporary file is not exactly equivalent. A program may choose to seek though the contents of a file, but data coming off a pipe is not seekable. A better examlp would be to use mkfifo to create a named pipe, then start B in the background reading from the pipe, and then A writing to it. This is nit-picking though, as the effect would be the same.

      – Kusalananda
      5 hours ago






    • 1





      @AlexVong The simplifications made in that article divorce it from real pipelines; the parallel execution is truly semantic, not an optimisation. It's a reasonable lies-to-children explanation of monadic evaluation or composition for someone who's seen shell pipelines, but it's not valid in the other direction. Kusalananda's fifo version is closer, but the error propagation parts of the model are genuinely important and not replicable. (all of which I say as someone who is very on the "shell pipelines are just function composition" train)

      – Michael Homer
      2 hours ago








    • 1





      @AlexVong No, that's completely off track. That isn't able to explain even something simple like yes | sed 10q

      – Uncle Billy
      1 hour ago


















    14














    The only thing about your question that stands out as wrong is that you say




    A would run first, then B gets the stdout of A




    In fact, both programs would be started at pretty much the same time. If there's no input for B when it tries to read, it will block until there is input to read. Likewise, if there's nobody reading the output from A, its writes will block until its output is read (some of it will be buffered by the pipe).



    The only thing synchronising the processes that take part in a pipeline is the I/O, i.e. the reading and writing. If no writing or reading happens, then the two processes will run totally independent of each other. If one ignores the reading or writing of the other, the ignored process will block and eventually be killed by a SIGPIPE signal (if writing) or get an end-of-file condition on its standard input stream (if reading) when the other process terminates.



    The idiomatic way to describe A | B is that it's a pipeline containing two programs. The output produced on standard output from the first program is available to be read on the standard input by the second ("[the output of] A is piped into B"). The shell does the required plumbing to allow this to happen.



    If you want to use the words "consumer" and "producer", I suppose that's ok too.



    The fact that these are programs written in C is not relevant. The fact that this is Linux, macOS, OpenBSD or AIX is not relevant.






    share|improve this answer


























    • Actually, we can think of having A and B running in parallel as an optimization. The command is equivalent to ./A > tmp_file && ./B < tmp_file, which first save the output of A to tmp_file and then give it as an input to B. This information is taken from: okmij.org/ftp/Computation/monadic-shell.html (I change the command slightly)

      – Alex Vong
      7 hours ago








    • 1





      Writing to a temporary file was used in DOS, as that didn't support multiple processes.

      – CSM
      5 hours ago






    • 1





      @AlexVong Note though that your example with a temporary file is not exactly equivalent. A program may choose to seek though the contents of a file, but data coming off a pipe is not seekable. A better examlp would be to use mkfifo to create a named pipe, then start B in the background reading from the pipe, and then A writing to it. This is nit-picking though, as the effect would be the same.

      – Kusalananda
      5 hours ago






    • 1





      @AlexVong The simplifications made in that article divorce it from real pipelines; the parallel execution is truly semantic, not an optimisation. It's a reasonable lies-to-children explanation of monadic evaluation or composition for someone who's seen shell pipelines, but it's not valid in the other direction. Kusalananda's fifo version is closer, but the error propagation parts of the model are genuinely important and not replicable. (all of which I say as someone who is very on the "shell pipelines are just function composition" train)

      – Michael Homer
      2 hours ago








    • 1





      @AlexVong No, that's completely off track. That isn't able to explain even something simple like yes | sed 10q

      – Uncle Billy
      1 hour ago
















    14












    14








    14







    The only thing about your question that stands out as wrong is that you say




    A would run first, then B gets the stdout of A




    In fact, both programs would be started at pretty much the same time. If there's no input for B when it tries to read, it will block until there is input to read. Likewise, if there's nobody reading the output from A, its writes will block until its output is read (some of it will be buffered by the pipe).



    The only thing synchronising the processes that take part in a pipeline is the I/O, i.e. the reading and writing. If no writing or reading happens, then the two processes will run totally independent of each other. If one ignores the reading or writing of the other, the ignored process will block and eventually be killed by a SIGPIPE signal (if writing) or get an end-of-file condition on its standard input stream (if reading) when the other process terminates.



    The idiomatic way to describe A | B is that it's a pipeline containing two programs. The output produced on standard output from the first program is available to be read on the standard input by the second ("[the output of] A is piped into B"). The shell does the required plumbing to allow this to happen.



    If you want to use the words "consumer" and "producer", I suppose that's ok too.



    The fact that these are programs written in C is not relevant. The fact that this is Linux, macOS, OpenBSD or AIX is not relevant.






    share|improve this answer















    The only thing about your question that stands out as wrong is that you say




    A would run first, then B gets the stdout of A




    In fact, both programs would be started at pretty much the same time. If there's no input for B when it tries to read, it will block until there is input to read. Likewise, if there's nobody reading the output from A, its writes will block until its output is read (some of it will be buffered by the pipe).



    The only thing synchronising the processes that take part in a pipeline is the I/O, i.e. the reading and writing. If no writing or reading happens, then the two processes will run totally independent of each other. If one ignores the reading or writing of the other, the ignored process will block and eventually be killed by a SIGPIPE signal (if writing) or get an end-of-file condition on its standard input stream (if reading) when the other process terminates.



    The idiomatic way to describe A | B is that it's a pipeline containing two programs. The output produced on standard output from the first program is available to be read on the standard input by the second ("[the output of] A is piped into B"). The shell does the required plumbing to allow this to happen.



    If you want to use the words "consumer" and "producer", I suppose that's ok too.



    The fact that these are programs written in C is not relevant. The fact that this is Linux, macOS, OpenBSD or AIX is not relevant.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 1 hour ago

























    answered 11 hours ago









    KusalanandaKusalananda

    143k18267443




    143k18267443













    • Actually, we can think of having A and B running in parallel as an optimization. The command is equivalent to ./A > tmp_file && ./B < tmp_file, which first save the output of A to tmp_file and then give it as an input to B. This information is taken from: okmij.org/ftp/Computation/monadic-shell.html (I change the command slightly)

      – Alex Vong
      7 hours ago








    • 1





      Writing to a temporary file was used in DOS, as that didn't support multiple processes.

      – CSM
      5 hours ago






    • 1





      @AlexVong Note though that your example with a temporary file is not exactly equivalent. A program may choose to seek though the contents of a file, but data coming off a pipe is not seekable. A better examlp would be to use mkfifo to create a named pipe, then start B in the background reading from the pipe, and then A writing to it. This is nit-picking though, as the effect would be the same.

      – Kusalananda
      5 hours ago






    • 1





      @AlexVong The simplifications made in that article divorce it from real pipelines; the parallel execution is truly semantic, not an optimisation. It's a reasonable lies-to-children explanation of monadic evaluation or composition for someone who's seen shell pipelines, but it's not valid in the other direction. Kusalananda's fifo version is closer, but the error propagation parts of the model are genuinely important and not replicable. (all of which I say as someone who is very on the "shell pipelines are just function composition" train)

      – Michael Homer
      2 hours ago








    • 1





      @AlexVong No, that's completely off track. That isn't able to explain even something simple like yes | sed 10q

      – Uncle Billy
      1 hour ago





















    • Actually, we can think of having A and B running in parallel as an optimization. The command is equivalent to ./A > tmp_file && ./B < tmp_file, which first save the output of A to tmp_file and then give it as an input to B. This information is taken from: okmij.org/ftp/Computation/monadic-shell.html (I change the command slightly)

      – Alex Vong
      7 hours ago








    • 1





      Writing to a temporary file was used in DOS, as that didn't support multiple processes.

      – CSM
      5 hours ago






    • 1





      @AlexVong Note though that your example with a temporary file is not exactly equivalent. A program may choose to seek though the contents of a file, but data coming off a pipe is not seekable. A better examlp would be to use mkfifo to create a named pipe, then start B in the background reading from the pipe, and then A writing to it. This is nit-picking though, as the effect would be the same.

      – Kusalananda
      5 hours ago






    • 1





      @AlexVong The simplifications made in that article divorce it from real pipelines; the parallel execution is truly semantic, not an optimisation. It's a reasonable lies-to-children explanation of monadic evaluation or composition for someone who's seen shell pipelines, but it's not valid in the other direction. Kusalananda's fifo version is closer, but the error propagation parts of the model are genuinely important and not replicable. (all of which I say as someone who is very on the "shell pipelines are just function composition" train)

      – Michael Homer
      2 hours ago








    • 1





      @AlexVong No, that's completely off track. That isn't able to explain even something simple like yes | sed 10q

      – Uncle Billy
      1 hour ago



















    Actually, we can think of having A and B running in parallel as an optimization. The command is equivalent to ./A > tmp_file && ./B < tmp_file, which first save the output of A to tmp_file and then give it as an input to B. This information is taken from: okmij.org/ftp/Computation/monadic-shell.html (I change the command slightly)

    – Alex Vong
    7 hours ago







    Actually, we can think of having A and B running in parallel as an optimization. The command is equivalent to ./A > tmp_file && ./B < tmp_file, which first save the output of A to tmp_file and then give it as an input to B. This information is taken from: okmij.org/ftp/Computation/monadic-shell.html (I change the command slightly)

    – Alex Vong
    7 hours ago






    1




    1





    Writing to a temporary file was used in DOS, as that didn't support multiple processes.

    – CSM
    5 hours ago





    Writing to a temporary file was used in DOS, as that didn't support multiple processes.

    – CSM
    5 hours ago




    1




    1





    @AlexVong Note though that your example with a temporary file is not exactly equivalent. A program may choose to seek though the contents of a file, but data coming off a pipe is not seekable. A better examlp would be to use mkfifo to create a named pipe, then start B in the background reading from the pipe, and then A writing to it. This is nit-picking though, as the effect would be the same.

    – Kusalananda
    5 hours ago





    @AlexVong Note though that your example with a temporary file is not exactly equivalent. A program may choose to seek though the contents of a file, but data coming off a pipe is not seekable. A better examlp would be to use mkfifo to create a named pipe, then start B in the background reading from the pipe, and then A writing to it. This is nit-picking though, as the effect would be the same.

    – Kusalananda
    5 hours ago




    1




    1





    @AlexVong The simplifications made in that article divorce it from real pipelines; the parallel execution is truly semantic, not an optimisation. It's a reasonable lies-to-children explanation of monadic evaluation or composition for someone who's seen shell pipelines, but it's not valid in the other direction. Kusalananda's fifo version is closer, but the error propagation parts of the model are genuinely important and not replicable. (all of which I say as someone who is very on the "shell pipelines are just function composition" train)

    – Michael Homer
    2 hours ago







    @AlexVong The simplifications made in that article divorce it from real pipelines; the parallel execution is truly semantic, not an optimisation. It's a reasonable lies-to-children explanation of monadic evaluation or composition for someone who's seen shell pipelines, but it's not valid in the other direction. Kusalananda's fifo version is closer, but the error propagation parts of the model are genuinely important and not replicable. (all of which I say as someone who is very on the "shell pipelines are just function composition" train)

    – Michael Homer
    2 hours ago






    1




    1





    @AlexVong No, that's completely off track. That isn't able to explain even something simple like yes | sed 10q

    – Uncle Billy
    1 hour ago







    @AlexVong No, that's completely off track. That isn't able to explain even something simple like yes | sed 10q

    – Uncle Billy
    1 hour ago















    0














    The term usually used in documentation is "pipeline" , which consists of one or more commands, see POSIX definition So technically speaking, that's two commands you have there, two subprocesses for the shell (either fork()+exec()'ed external commands or subshells )



    As for producer-consumer part, the pipeline can be described by that pattern, since:




    • Producer and Consumer share fixed-size buffer, and at least on Linux and MacOS X, there's fixed size for pipeline buffer

    • Producer and Consumer are loosely-coupled, commands in pipeline don't know of each other's existence ( unless they are actively checking /proc/<pid>/fd directory ).

    • Producers write to stdout and consumers read stdin as if they were a single command being executed, aka they can exist without each other.


    The difference I see here is that unlike Producer-Consumer in other languges, shell commands use buffering and they write stdout once buffer is filled, but there's no mention that Producer-Consumer has to follow that rule - only wait when queue is filled or discard data (which is something else that pipeline doesn't do).






    share|improve this answer




























      0














      The term usually used in documentation is "pipeline" , which consists of one or more commands, see POSIX definition So technically speaking, that's two commands you have there, two subprocesses for the shell (either fork()+exec()'ed external commands or subshells )



      As for producer-consumer part, the pipeline can be described by that pattern, since:




      • Producer and Consumer share fixed-size buffer, and at least on Linux and MacOS X, there's fixed size for pipeline buffer

      • Producer and Consumer are loosely-coupled, commands in pipeline don't know of each other's existence ( unless they are actively checking /proc/<pid>/fd directory ).

      • Producers write to stdout and consumers read stdin as if they were a single command being executed, aka they can exist without each other.


      The difference I see here is that unlike Producer-Consumer in other languges, shell commands use buffering and they write stdout once buffer is filled, but there's no mention that Producer-Consumer has to follow that rule - only wait when queue is filled or discard data (which is something else that pipeline doesn't do).






      share|improve this answer


























        0












        0








        0







        The term usually used in documentation is "pipeline" , which consists of one or more commands, see POSIX definition So technically speaking, that's two commands you have there, two subprocesses for the shell (either fork()+exec()'ed external commands or subshells )



        As for producer-consumer part, the pipeline can be described by that pattern, since:




        • Producer and Consumer share fixed-size buffer, and at least on Linux and MacOS X, there's fixed size for pipeline buffer

        • Producer and Consumer are loosely-coupled, commands in pipeline don't know of each other's existence ( unless they are actively checking /proc/<pid>/fd directory ).

        • Producers write to stdout and consumers read stdin as if they were a single command being executed, aka they can exist without each other.


        The difference I see here is that unlike Producer-Consumer in other languges, shell commands use buffering and they write stdout once buffer is filled, but there's no mention that Producer-Consumer has to follow that rule - only wait when queue is filled or discard data (which is something else that pipeline doesn't do).






        share|improve this answer













        The term usually used in documentation is "pipeline" , which consists of one or more commands, see POSIX definition So technically speaking, that's two commands you have there, two subprocesses for the shell (either fork()+exec()'ed external commands or subshells )



        As for producer-consumer part, the pipeline can be described by that pattern, since:




        • Producer and Consumer share fixed-size buffer, and at least on Linux and MacOS X, there's fixed size for pipeline buffer

        • Producer and Consumer are loosely-coupled, commands in pipeline don't know of each other's existence ( unless they are actively checking /proc/<pid>/fd directory ).

        • Producers write to stdout and consumers read stdin as if they were a single command being executed, aka they can exist without each other.


        The difference I see here is that unlike Producer-Consumer in other languges, shell commands use buffering and they write stdout once buffer is filled, but there's no mention that Producer-Consumer has to follow that rule - only wait when queue is filled or discard data (which is something else that pipeline doesn't do).







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 1 hour ago









        Sergiy KolodyazhnyySergiy Kolodyazhnyy

        10.7k42765




        10.7k42765






















            nihulus is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            nihulus is a new contributor. Be nice, and check out our Code of Conduct.













            nihulus is a new contributor. Be nice, and check out our Code of Conduct.












            nihulus is a new contributor. Be nice, and check out our Code of Conduct.
















            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%2f513657%2funderstanding-piped-commands-in-gnu-linux%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

            “%fieldName is a required field.”, in Magento2 REST API Call for GET Method Type The Next...

            How to change City field to a dropdown in Checkout step Magento 2Magento 2 : How to change UI field(s)...

            變成蝙蝠會怎樣? 參考資料 外部連結 导航菜单Thomas Nagel, "What is it like to be a...