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?
What is "Lambda" in Heston's original paper on stochastic volatility models?
Diophantine equation 3^a+1=3^b+5^c
Short story about astronauts fertilizing soil with their own bodies
How to achieve cat-like agility?
French equivalents of おしゃれは足元から (Every good outfit starts with the shoes)
Noise in Eigenvalues plot
Any stored/leased 737s that could substitute for grounded MAXs?
Statistical analysis applied to methods coming out of Machine Learning
What is a more techy Technical Writer job title that isn't cutesy or confusing?
Is there a verb for listening stealthily?
Did John Wesley plagiarize Matthew Henry...?
As a dual citizen, my US passport will expire one day after traveling to the US. Will this work?
Weaponising the Grasp-at-a-Distance spell
newbie Q : How to read an output file in one command line
Baking rewards as operations
"Destructive power" carried by a B-52?
Table formatting with tabularx?
Russian equivalents of おしゃれは足元から (Every good outfit starts with the shoes)
Should man-made satellites feature an intelligent inverted "cow catcher"?
First paper to introduce the "principal-agent problem"
By what mechanism was the 2017 UK General Election called?
Can two people see the same photon?
How to resize main filesystem
Adapting the Chinese Remainder Theorem (CRT) for integers to polynomials
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;
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
New contributor
add a comment |
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
New contributor
Related: In what order do piped commands run?
– G-Man
4 hours ago
It's not command, it's an kenerl object created by bash process, which is used as stdout of process A and stdin as B. Two processes are started nearly at the same time.
– 炸鱼薯条德里克
1 hour ago
@炸鱼 You're correct - for kernel pipeline is an object in pipefs filesystem, but as far as shell itself is concerned - technically that's a pipeline command
– Sergiy Kolodyazhnyy
32 mins ago
add a comment |
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
New contributor
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
pipe c
New contributor
New contributor
edited 2 hours ago
JL2210
1033
1033
New contributor
asked 14 hours ago
nihulusnihulus
1413
1413
New contributor
New contributor
Related: In what order do piped commands run?
– G-Man
4 hours ago
It's not command, it's an kenerl object created by bash process, which is used as stdout of process A and stdin as B. Two processes are started nearly at the same time.
– 炸鱼薯条德里克
1 hour ago
@炸鱼 You're correct - for kernel pipeline is an object in pipefs filesystem, but as far as shell itself is concerned - technically that's a pipeline command
– Sergiy Kolodyazhnyy
32 mins ago
add a comment |
Related: In what order do piped commands run?
– G-Man
4 hours ago
It's not command, it's an kenerl object created by bash process, which is used as stdout of process A and stdin as B. Two processes are started nearly at the same time.
– 炸鱼薯条德里克
1 hour ago
@炸鱼 You're correct - for kernel pipeline is an object in pipefs filesystem, but as far as shell itself is concerned - technically that's a pipeline command
– Sergiy Kolodyazhnyy
32 mins ago
Related: In what order do piped commands run?
– G-Man
4 hours ago
Related: In what order do piped commands run?
– G-Man
4 hours ago
It's not command, it's an kenerl object created by bash process, which is used as stdout of process A and stdin as B. Two processes are started nearly at the same time.
– 炸鱼薯条德里克
1 hour ago
It's not command, it's an kenerl object created by bash process, which is used as stdout of process A and stdin as B. Two processes are started nearly at the same time.
– 炸鱼薯条德里克
1 hour ago
@炸鱼 You're correct - for kernel pipeline is an object in pipefs filesystem, but as far as shell itself is concerned - technically that's a pipeline command
– Sergiy Kolodyazhnyy
32 mins ago
@炸鱼 You're correct - for kernel pipeline is an object in pipefs filesystem, but as far as shell itself is concerned - technically that's a pipeline command
– Sergiy Kolodyazhnyy
32 mins ago
add a comment |
2 Answers
2
active
oldest
votes
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.
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 totmp_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
9 hours ago
1
Writing to a temporary file was used in DOS, as that didn't support multiple processes.
– CSM
8 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 usemkfifo
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♦
8 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
4 hours ago
1
@AlexVong No, that's completely off track. That isn't able to explain even something simple likeyes | sed 10q
– Uncle Billy
3 hours ago
|
show 4 more comments
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 readstdin
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).
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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 totmp_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
9 hours ago
1
Writing to a temporary file was used in DOS, as that didn't support multiple processes.
– CSM
8 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 usemkfifo
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♦
8 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
4 hours ago
1
@AlexVong No, that's completely off track. That isn't able to explain even something simple likeyes | sed 10q
– Uncle Billy
3 hours ago
|
show 4 more comments
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.
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 totmp_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
9 hours ago
1
Writing to a temporary file was used in DOS, as that didn't support multiple processes.
– CSM
8 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 usemkfifo
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♦
8 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
4 hours ago
1
@AlexVong No, that's completely off track. That isn't able to explain even something simple likeyes | sed 10q
– Uncle Billy
3 hours ago
|
show 4 more comments
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.
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.
edited 4 hours ago
answered 13 hours ago
Kusalananda♦Kusalananda
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 totmp_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
9 hours ago
1
Writing to a temporary file was used in DOS, as that didn't support multiple processes.
– CSM
8 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 usemkfifo
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♦
8 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
4 hours ago
1
@AlexVong No, that's completely off track. That isn't able to explain even something simple likeyes | sed 10q
– Uncle Billy
3 hours ago
|
show 4 more comments
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 totmp_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
9 hours ago
1
Writing to a temporary file was used in DOS, as that didn't support multiple processes.
– CSM
8 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 usemkfifo
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♦
8 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
4 hours ago
1
@AlexVong No, that's completely off track. That isn't able to explain even something simple likeyes | sed 10q
– Uncle Billy
3 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
9 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
9 hours ago
1
1
Writing to a temporary file was used in DOS, as that didn't support multiple processes.
– CSM
8 hours ago
Writing to a temporary file was used in DOS, as that didn't support multiple processes.
– CSM
8 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♦
8 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♦
8 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
4 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
4 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
3 hours ago
@AlexVong No, that's completely off track. That isn't able to explain even something simple like
yes | sed 10q
– Uncle Billy
3 hours ago
|
show 4 more comments
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 readstdin
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).
add a comment |
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 readstdin
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).
add a comment |
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 readstdin
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).
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 readstdin
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).
answered 3 hours ago
Sergiy KolodyazhnyySergiy Kolodyazhnyy
10.7k42765
10.7k42765
add a comment |
add a comment |
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.
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Related: In what order do piped commands run?
– G-Man
4 hours ago
It's not command, it's an kenerl object created by bash process, which is used as stdout of process A and stdin as B. Two processes are started nearly at the same time.
– 炸鱼薯条德里克
1 hour ago
@炸鱼 You're correct - for kernel pipeline is an object in pipefs filesystem, but as far as shell itself is concerned - technically that's a pipeline command
– Sergiy Kolodyazhnyy
32 mins ago