What are the main execution stages in Linux (how does a program basically gets executed in Linux)?
Clash Royale CLAN TAG#URR8PPP
up vote
5
down vote
favorite
I understand that there are two stages of execution in Linux, dealing with every command we run. I'll name this how I understand them because I don't know the original phrasing:
Shell handling --- The shell edits the command (splitting it to different rows etc) and all of this is done in a different shell than the current one.
Execution of the outcome after shell handling (in the original shell we work with).
Can someone please answer with the name of these operations and reference to some reading material he finds best for new learners on this?
executable
asked Nov 11 '17 at 22:51
Arcticooling
83123
add a comment |Â
up vote
5
down vote
favorite
I understand that there are two stages of execution in Linux, dealing with every command we run. I'll name this how I understand them because I don't know the original phrasing:
Shell handling --- The shell edits the command (splitting it to different rows etc) and all of this is done in a different shell than the current one.
Execution of the outcome after shell handling (in the original shell we work with).
Can someone please answer with the name of these operations and reference to some reading material he finds best for new learners on this?
executable
asked Nov 11 '17 at 22:51
Arcticooling
83123
2
This answer is quite relevant to your question
– Basile Starynkevitch
Nov 11 '17 at 23:12
add a comment |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I understand that there are two stages of execution in Linux, dealing with every command we run. I'll name this how I understand them because I don't know the original phrasing:
Shell handling --- The shell edits the command (splitting it to different rows etc) and all of this is done in a different shell than the current one.
Execution of the outcome after shell handling (in the original shell we work with).
Can someone please answer with the name of these operations and reference to some reading material he finds best for new learners on this?
executable
asked Nov 11 '17 at 22:51
Arcticooling
83123
I understand that there are two stages of execution in Linux, dealing with every command we run. I'll name this how I understand them because I don't know the original phrasing:
Shell handling --- The shell edits the command (splitting it to different rows etc) and all of this is done in a different shell than the current one.
Execution of the outcome after shell handling (in the original shell we work with).
Can someone please answer with the name of these operations and reference to some reading material he finds best for new learners on this?
executable
asked Nov 11 '17 at 22:51
Arcticooling
83123
edited Nov 12 '17 at 0:18
asked Nov 11 '17 at 22:51
Arcticooling
83123
asked Nov 11 '17 at 22:51
Arcticooling
83123
asked Nov 11 '17 at 22:51
Arcticooling
83123
83123
2
This answer is quite relevant to your question
– Basile Starynkevitch
Nov 11 '17 at 23:12
add a comment |Â
2
This answer is quite relevant to your question
– Basile Starynkevitch
Nov 11 '17 at 23:12
2
2
This answer is quite relevant to your question
– Basile Starynkevitch
Nov 11 '17 at 23:12
This answer is quite relevant to your question
– Basile Starynkevitch
Nov 11 '17 at 23:12
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
5
down vote
accepted
- Shell handling --- The shell edits the command (splitting it to different rows etc)
Yeah, sort of. The shell gets a command as a single string (usually one line of input), and turns it into a set of strings that actually go to the executable it eventually runs. The shell splits the whitespace separated words from a single string to multiple strings, but also handles quotes, and expands variables etc.
So, something like
ls "$options" "/filename with spaces"
might result to the three strings ls, -l (from the value of $options), and /filename with spaces (quote removal). These get passed to the exec() system call that runs the program.
and all of this is done in a different shell than the current one.
No, not really. Some shell expansions (like $( ... )) spawn subshells to do the hard work, but that doesn't happen for a regular "simple" command line.
- Execution of the outcome after shell handling (in the original shell we work with).
Actually executing the program as the after the command line is parsed is a logically separate step. But technically that happens in another process, since the way for running another program on Unix involves first calling fork(), which creates a new process as a copy of the first one, and then calling exec() to replace this copy (of the shell) with the actual program to run (say ls in the example).
If the command is started with exec (as in exec ls, then the forking is skipped, and the shell replaces itself with command it's starting.
Like mentioned in the comments, shell builtins (like echo in many shells) also often run in the same process, without forking.
(All of the above is somewhat simplified. Real shells may have other features that are not described here.)
answered Nov 12 '17 at 0:09
ilkkachu
50.4k677138
So to simplify even more to new learners: The usual stuff is: 1. Parsing (maybe in the same shell), and 2. Execution (maybe in the same shell). If execution isn't in the same shell, forking will come between parsing and execution.
– Arcticooling
Nov 12 '17 at 0:15
1
@Arcticooling I'd like to point out that execution is almost always in another shell. The only time it isn't is if you use theexecbuiltin.
– HTNW
Nov 12 '17 at 4:04
… or any other special built-in.
– JdeBP
Nov 12 '17 at 11:29
I don't understand, @JdeBP instead what?
– Arcticooling
Nov 12 '17 at 12:23
unix.stackexchange.com/questions/11454 will prove instructive.
– JdeBP
Nov 12 '17 at 15:05
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
- Shell handling --- The shell edits the command (splitting it to different rows etc)
Yeah, sort of. The shell gets a command as a single string (usually one line of input), and turns it into a set of strings that actually go to the executable it eventually runs. The shell splits the whitespace separated words from a single string to multiple strings, but also handles quotes, and expands variables etc.
So, something like
ls "$options" "/filename with spaces"
might result to the three strings ls, -l (from the value of $options), and /filename with spaces (quote removal). These get passed to the exec() system call that runs the program.
and all of this is done in a different shell than the current one.
No, not really. Some shell expansions (like $( ... )) spawn subshells to do the hard work, but that doesn't happen for a regular "simple" command line.
- Execution of the outcome after shell handling (in the original shell we work with).
Actually executing the program as the after the command line is parsed is a logically separate step. But technically that happens in another process, since the way for running another program on Unix involves first calling fork(), which creates a new process as a copy of the first one, and then calling exec() to replace this copy (of the shell) with the actual program to run (say ls in the example).
If the command is started with exec (as in exec ls, then the forking is skipped, and the shell replaces itself with command it's starting.
Like mentioned in the comments, shell builtins (like echo in many shells) also often run in the same process, without forking.
(All of the above is somewhat simplified. Real shells may have other features that are not described here.)
answered Nov 12 '17 at 0:09
ilkkachu
50.4k677138
So to simplify even more to new learners: The usual stuff is: 1. Parsing (maybe in the same shell), and 2. Execution (maybe in the same shell). If execution isn't in the same shell, forking will come between parsing and execution.
– Arcticooling
Nov 12 '17 at 0:15
1
@Arcticooling I'd like to point out that execution is almost always in another shell. The only time it isn't is if you use theexecbuiltin.
– HTNW
Nov 12 '17 at 4:04
… or any other special built-in.
– JdeBP
Nov 12 '17 at 11:29
I don't understand, @JdeBP instead what?
– Arcticooling
Nov 12 '17 at 12:23
unix.stackexchange.com/questions/11454 will prove instructive.
– JdeBP
Nov 12 '17 at 15:05
 |Â
show 1 more comment
up vote
5
down vote
accepted
- Shell handling --- The shell edits the command (splitting it to different rows etc)
Yeah, sort of. The shell gets a command as a single string (usually one line of input), and turns it into a set of strings that actually go to the executable it eventually runs. The shell splits the whitespace separated words from a single string to multiple strings, but also handles quotes, and expands variables etc.
So, something like
ls "$options" "/filename with spaces"
might result to the three strings ls, -l (from the value of $options), and /filename with spaces (quote removal). These get passed to the exec() system call that runs the program.
and all of this is done in a different shell than the current one.
No, not really. Some shell expansions (like $( ... )) spawn subshells to do the hard work, but that doesn't happen for a regular "simple" command line.
- Execution of the outcome after shell handling (in the original shell we work with).
Actually executing the program as the after the command line is parsed is a logically separate step. But technically that happens in another process, since the way for running another program on Unix involves first calling fork(), which creates a new process as a copy of the first one, and then calling exec() to replace this copy (of the shell) with the actual program to run (say ls in the example).
If the command is started with exec (as in exec ls, then the forking is skipped, and the shell replaces itself with command it's starting.
Like mentioned in the comments, shell builtins (like echo in many shells) also often run in the same process, without forking.
(All of the above is somewhat simplified. Real shells may have other features that are not described here.)
answered Nov 12 '17 at 0:09
ilkkachu
50.4k677138
So to simplify even more to new learners: The usual stuff is: 1. Parsing (maybe in the same shell), and 2. Execution (maybe in the same shell). If execution isn't in the same shell, forking will come between parsing and execution.
– Arcticooling
Nov 12 '17 at 0:15
1
@Arcticooling I'd like to point out that execution is almost always in another shell. The only time it isn't is if you use theexecbuiltin.
– HTNW
Nov 12 '17 at 4:04
… or any other special built-in.
– JdeBP
Nov 12 '17 at 11:29
I don't understand, @JdeBP instead what?
– Arcticooling
Nov 12 '17 at 12:23
unix.stackexchange.com/questions/11454 will prove instructive.
– JdeBP
Nov 12 '17 at 15:05
 |Â
show 1 more comment
up vote
5
down vote
accepted
up vote
5
down vote
accepted
- Shell handling --- The shell edits the command (splitting it to different rows etc)
Yeah, sort of. The shell gets a command as a single string (usually one line of input), and turns it into a set of strings that actually go to the executable it eventually runs. The shell splits the whitespace separated words from a single string to multiple strings, but also handles quotes, and expands variables etc.
So, something like
ls "$options" "/filename with spaces"
might result to the three strings ls, -l (from the value of $options), and /filename with spaces (quote removal). These get passed to the exec() system call that runs the program.
and all of this is done in a different shell than the current one.
No, not really. Some shell expansions (like $( ... )) spawn subshells to do the hard work, but that doesn't happen for a regular "simple" command line.
- Execution of the outcome after shell handling (in the original shell we work with).
Actually executing the program as the after the command line is parsed is a logically separate step. But technically that happens in another process, since the way for running another program on Unix involves first calling fork(), which creates a new process as a copy of the first one, and then calling exec() to replace this copy (of the shell) with the actual program to run (say ls in the example).
If the command is started with exec (as in exec ls, then the forking is skipped, and the shell replaces itself with command it's starting.
Like mentioned in the comments, shell builtins (like echo in many shells) also often run in the same process, without forking.
(All of the above is somewhat simplified. Real shells may have other features that are not described here.)
answered Nov 12 '17 at 0:09
ilkkachu
50.4k677138
- Shell handling --- The shell edits the command (splitting it to different rows etc)
Yeah, sort of. The shell gets a command as a single string (usually one line of input), and turns it into a set of strings that actually go to the executable it eventually runs. The shell splits the whitespace separated words from a single string to multiple strings, but also handles quotes, and expands variables etc.
So, something like
ls "$options" "/filename with spaces"
might result to the three strings ls, -l (from the value of $options), and /filename with spaces (quote removal). These get passed to the exec() system call that runs the program.
and all of this is done in a different shell than the current one.
No, not really. Some shell expansions (like $( ... )) spawn subshells to do the hard work, but that doesn't happen for a regular "simple" command line.
- Execution of the outcome after shell handling (in the original shell we work with).
Actually executing the program as the after the command line is parsed is a logically separate step. But technically that happens in another process, since the way for running another program on Unix involves first calling fork(), which creates a new process as a copy of the first one, and then calling exec() to replace this copy (of the shell) with the actual program to run (say ls in the example).
If the command is started with exec (as in exec ls, then the forking is skipped, and the shell replaces itself with command it's starting.
Like mentioned in the comments, shell builtins (like echo in many shells) also often run in the same process, without forking.
(All of the above is somewhat simplified. Real shells may have other features that are not described here.)
answered Nov 12 '17 at 0:09
ilkkachu
50.4k677138
edited Nov 13 '17 at 10:49
answered Nov 12 '17 at 0:09
ilkkachu
50.4k677138
answered Nov 12 '17 at 0:09
ilkkachu
50.4k677138
answered Nov 12 '17 at 0:09
ilkkachu
50.4k677138
50.4k677138
So to simplify even more to new learners: The usual stuff is: 1. Parsing (maybe in the same shell), and 2. Execution (maybe in the same shell). If execution isn't in the same shell, forking will come between parsing and execution.
– Arcticooling
Nov 12 '17 at 0:15
1
@Arcticooling I'd like to point out that execution is almost always in another shell. The only time it isn't is if you use theexecbuiltin.
– HTNW
Nov 12 '17 at 4:04
… or any other special built-in.
– JdeBP
Nov 12 '17 at 11:29
I don't understand, @JdeBP instead what?
– Arcticooling
Nov 12 '17 at 12:23
unix.stackexchange.com/questions/11454 will prove instructive.
– JdeBP
Nov 12 '17 at 15:05
 |Â
show 1 more comment
So to simplify even more to new learners: The usual stuff is: 1. Parsing (maybe in the same shell), and 2. Execution (maybe in the same shell). If execution isn't in the same shell, forking will come between parsing and execution.
– Arcticooling
Nov 12 '17 at 0:15
1
@Arcticooling I'd like to point out that execution is almost always in another shell. The only time it isn't is if you use theexecbuiltin.
– HTNW
Nov 12 '17 at 4:04
… or any other special built-in.
– JdeBP
Nov 12 '17 at 11:29
I don't understand, @JdeBP instead what?
– Arcticooling
Nov 12 '17 at 12:23
unix.stackexchange.com/questions/11454 will prove instructive.
– JdeBP
Nov 12 '17 at 15:05
So to simplify even more to new learners: The usual stuff is: 1. Parsing (maybe in the same shell), and 2. Execution (maybe in the same shell). If execution isn't in the same shell, forking will come between parsing and execution.
– Arcticooling
Nov 12 '17 at 0:15
So to simplify even more to new learners: The usual stuff is: 1. Parsing (maybe in the same shell), and 2. Execution (maybe in the same shell). If execution isn't in the same shell, forking will come between parsing and execution.
– Arcticooling
Nov 12 '17 at 0:15
1
1
@Arcticooling I'd like to point out that execution is almost always in another shell. The only time it isn't is if you use the
exec builtin.– HTNW
Nov 12 '17 at 4:04
@Arcticooling I'd like to point out that execution is almost always in another shell. The only time it isn't is if you use the
exec builtin.– HTNW
Nov 12 '17 at 4:04
… or any other special built-in.
– JdeBP
Nov 12 '17 at 11:29
… or any other special built-in.
– JdeBP
Nov 12 '17 at 11:29
I don't understand, @JdeBP instead what?
– Arcticooling
Nov 12 '17 at 12:23
I don't understand, @JdeBP instead what?
– Arcticooling
Nov 12 '17 at 12:23
unix.stackexchange.com/questions/11454 will prove instructive.
– JdeBP
Nov 12 '17 at 15:05
unix.stackexchange.com/questions/11454 will prove instructive.
– JdeBP
Nov 12 '17 at 15:05
 |Â
show 1 more comment
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f403960%2fwhat-are-the-main-execution-stages-in-linux-how-does-a-program-basically-gets-e%23new-answer', 'question_page');
);
Post as a guest
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
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
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
2
This answer is quite relevant to your question
– Basile Starynkevitch
Nov 11 '17 at 23:12