ls require a separate process for its execution?
I know the reason why commands like
cd can't be executed by forking mechanism but is there any harm if
ls is executed without forking?
The answer is more or less that
At the very least, running
Since your shell's process image is replaced, the current shell is no longer accessible after doing this. For the shell to be able to continue to run after running ls, the command would have to be built into the shell.
Forking allows the replacement of a process that is not your primary shell, which means you can continue to run your shell afterwards.
The Bash Reference Manual states:
That is, shells are designed to only include built-in commands if:
However, here is no programming constraint that would prevent
Regarding the first reason - You want the shell to be as independent and resiliant as possible. You don't want the shell to get stuck on
Regarding the second reason - In many instances you might want to use a shell for a system that uses Busybox or other filesystem that has a different
Regarding the third reason - For an expressions such as
Regarding the fourth reason - Some
As a rule, shells implement commands as builtins only when those commands need to be implemented as builtins. Commands like
Looking at the list of builtins in bash, only the following builtins could be implemented as separate commands. For some of them, there would be a slight loss of functionality.
A few shells offer a significant number of additional builtins. There's sash, which is a shell designed to be a standalone binary for emergency repairs (when some external commands may not be usable). It has a built-in
I think that something people are missing here is the shear complexity of the GNU
Most shell builtins are chosen because they integrate with the shell in a way that external executables can't (the question points out
This do what you are looking for:
Also you can store filenames in array:
But it doesn’t care about spaces in names