Why are some bash commands both built-in and external?












1















Some commands are internal built-in bash commands while others are external (other programs). I see why certain commands need to be built-in. Some of the reasons are:




  1. If a command needs to change the internal state of the shell process.

  2. If a command performs a very basic operation in the shell.

  3. If a command is called often and needs to be made fast. An external command is executed by loading an external program and hence is slower.


But why are some commands both built-in and external, for eg echo and test? I understand echo is used a lot and thus is built-in (Reason 3). But then why also have it as an external command and have a binary for it in /bin/echo? The built-in version of echo will always take precedence over the external version and thus, the external version is hardly ever used. So, why then have an external version of it at all?






linux bash shell terminal







share|improve this question




















  • 1





    Consider also that bash is not the only shell out there. At some point in its history bash may have decided to make a command internal, e.g. for reason #3 - but there are still other shells invoking the tool, so it has to continue existing as an external command.

    – user4815162342
    Nov 19 '18 at 11:30
















1















Some commands are internal built-in bash commands while others are external (other programs). I see why certain commands need to be built-in. Some of the reasons are:




  1. If a command needs to change the internal state of the shell process.

  2. If a command performs a very basic operation in the shell.

  3. If a command is called often and needs to be made fast. An external command is executed by loading an external program and hence is slower.


But why are some commands both built-in and external, for eg echo and test? I understand echo is used a lot and thus is built-in (Reason 3). But then why also have it as an external command and have a binary for it in /bin/echo? The built-in version of echo will always take precedence over the external version and thus, the external version is hardly ever used. So, why then have an external version of it at all?






linux bash shell terminal







share|improve this question




















  • 1





    Consider also that bash is not the only shell out there. At some point in its history bash may have decided to make a command internal, e.g. for reason #3 - but there are still other shells invoking the tool, so it has to continue existing as an external command.

    – user4815162342
    Nov 19 '18 at 11:30














1












1








1








Some commands are internal built-in bash commands while others are external (other programs). I see why certain commands need to be built-in. Some of the reasons are:




  1. If a command needs to change the internal state of the shell process.

  2. If a command performs a very basic operation in the shell.

  3. If a command is called often and needs to be made fast. An external command is executed by loading an external program and hence is slower.


But why are some commands both built-in and external, for eg echo and test? I understand echo is used a lot and thus is built-in (Reason 3). But then why also have it as an external command and have a binary for it in /bin/echo? The built-in version of echo will always take precedence over the external version and thus, the external version is hardly ever used. So, why then have an external version of it at all?






linux bash shell terminal







share|improve this question
















Some commands are internal built-in bash commands while others are external (other programs). I see why certain commands need to be built-in. Some of the reasons are:




  1. If a command needs to change the internal state of the shell process.

  2. If a command performs a very basic operation in the shell.

  3. If a command is called often and needs to be made fast. An external command is executed by loading an external program and hence is slower.


But why are some commands both built-in and external, for eg echo and test? I understand echo is used a lot and thus is built-in (Reason 3). But then why also have it as an external command and have a binary for it in /bin/echo? The built-in version of echo will always take precedence over the external version and thus, the external version is hardly ever used. So, why then have an external version of it at all?






linux bash shell terminal




linux bash shell terminal






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 18 '18 at 20:14







Marko Cain

















asked Nov 18 '18 at 20:01









Marko CainMarko Cain

474




474








  • 1





    Consider also that bash is not the only shell out there. At some point in its history bash may have decided to make a command internal, e.g. for reason #3 - but there are still other shells invoking the tool, so it has to continue existing as an external command.

    – user4815162342
    Nov 19 '18 at 11:30














  • 1





    Consider also that bash is not the only shell out there. At some point in its history bash may have decided to make a command internal, e.g. for reason #3 - but there are still other shells invoking the tool, so it has to continue existing as an external command.

    – user4815162342
    Nov 19 '18 at 11:30








1




1





Consider also that bash is not the only shell out there. At some point in its history bash may have decided to make a command internal, e.g. for reason #3 - but there are still other shells invoking the tool, so it has to continue existing as an external command.

– user4815162342
Nov 19 '18 at 11:30





Consider also that bash is not the only shell out there. At some point in its history bash may have decided to make a command internal, e.g. for reason #3 - but there are still other shells invoking the tool, so it has to continue existing as an external command.

– user4815162342
Nov 19 '18 at 11:30












1 Answer
1






active

oldest

votes


















3














It's exactly your point 3. When a command does very little (echo is a good example) spawning a new process dominates the run time behavior. With growing disks and bandwidth and code bases you always reach a spot when you have so much data and so many files (our code base at work has 100k files!!) that one less spawn per file makes a difference of minutes.



That's also why the typical built-in is a drop-in replacement which takes (perhaps a superset of) the same arguments as the binary.



You also ask why the old binary is still retained even though bash has it as a built-in — the answer is that a lot of programs rely on the existence of that /bin/echo. It's actually standardized.



The bash is only one of many user interfaces and offline command interpreters. They all have different sets of built-ins. Some shells are purposefully small and rely a lot on what you could call "legacy" binaries. One example is ash and its successor, dash. dash is now the default /bin/sh in Ubuntu and Debian due to its speed, and is popular for embedded systems due to its small size. (But even dash has builtins for echo, test and dozens of other commands, and provides a command history for interactive use.)






share|improve this answer


























  • But why not have it only as an internal command then, like cd? What's the purpose of making it external as well?

    – Marko Cain
    Nov 18 '18 at 20:13













  • @MarkoCain Oh.... I'll answer that in the post.

    – Peter A. Schneider
    Nov 18 '18 at 20:14











  • Fedora (and RHEL?) does have an external /bin/cd script which simply calls the /bin/sh builtin cd command. It's only purpose, as far as I can tell, is to check whether a "cd" command will succeed, without actually changing directories in the current shell.

    – simon3270
    Nov 20 '18 at 11:03











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53364895%2fwhy-are-some-bash-commands-both-built-in-and-external%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














It's exactly your point 3. When a command does very little (echo is a good example) spawning a new process dominates the run time behavior. With growing disks and bandwidth and code bases you always reach a spot when you have so much data and so many files (our code base at work has 100k files!!) that one less spawn per file makes a difference of minutes.



That's also why the typical built-in is a drop-in replacement which takes (perhaps a superset of) the same arguments as the binary.



You also ask why the old binary is still retained even though bash has it as a built-in — the answer is that a lot of programs rely on the existence of that /bin/echo. It's actually standardized.



The bash is only one of many user interfaces and offline command interpreters. They all have different sets of built-ins. Some shells are purposefully small and rely a lot on what you could call "legacy" binaries. One example is ash and its successor, dash. dash is now the default /bin/sh in Ubuntu and Debian due to its speed, and is popular for embedded systems due to its small size. (But even dash has builtins for echo, test and dozens of other commands, and provides a command history for interactive use.)






share|improve this answer


























  • But why not have it only as an internal command then, like cd? What's the purpose of making it external as well?

    – Marko Cain
    Nov 18 '18 at 20:13













  • @MarkoCain Oh.... I'll answer that in the post.

    – Peter A. Schneider
    Nov 18 '18 at 20:14











  • Fedora (and RHEL?) does have an external /bin/cd script which simply calls the /bin/sh builtin cd command. It's only purpose, as far as I can tell, is to check whether a "cd" command will succeed, without actually changing directories in the current shell.

    – simon3270
    Nov 20 '18 at 11:03
















3














It's exactly your point 3. When a command does very little (echo is a good example) spawning a new process dominates the run time behavior. With growing disks and bandwidth and code bases you always reach a spot when you have so much data and so many files (our code base at work has 100k files!!) that one less spawn per file makes a difference of minutes.



That's also why the typical built-in is a drop-in replacement which takes (perhaps a superset of) the same arguments as the binary.



You also ask why the old binary is still retained even though bash has it as a built-in — the answer is that a lot of programs rely on the existence of that /bin/echo. It's actually standardized.



The bash is only one of many user interfaces and offline command interpreters. They all have different sets of built-ins. Some shells are purposefully small and rely a lot on what you could call "legacy" binaries. One example is ash and its successor, dash. dash is now the default /bin/sh in Ubuntu and Debian due to its speed, and is popular for embedded systems due to its small size. (But even dash has builtins for echo, test and dozens of other commands, and provides a command history for interactive use.)






share|improve this answer


























  • But why not have it only as an internal command then, like cd? What's the purpose of making it external as well?

    – Marko Cain
    Nov 18 '18 at 20:13













  • @MarkoCain Oh.... I'll answer that in the post.

    – Peter A. Schneider
    Nov 18 '18 at 20:14











  • Fedora (and RHEL?) does have an external /bin/cd script which simply calls the /bin/sh builtin cd command. It's only purpose, as far as I can tell, is to check whether a "cd" command will succeed, without actually changing directories in the current shell.

    – simon3270
    Nov 20 '18 at 11:03














3












3








3







It's exactly your point 3. When a command does very little (echo is a good example) spawning a new process dominates the run time behavior. With growing disks and bandwidth and code bases you always reach a spot when you have so much data and so many files (our code base at work has 100k files!!) that one less spawn per file makes a difference of minutes.



That's also why the typical built-in is a drop-in replacement which takes (perhaps a superset of) the same arguments as the binary.



You also ask why the old binary is still retained even though bash has it as a built-in — the answer is that a lot of programs rely on the existence of that /bin/echo. It's actually standardized.



The bash is only one of many user interfaces and offline command interpreters. They all have different sets of built-ins. Some shells are purposefully small and rely a lot on what you could call "legacy" binaries. One example is ash and its successor, dash. dash is now the default /bin/sh in Ubuntu and Debian due to its speed, and is popular for embedded systems due to its small size. (But even dash has builtins for echo, test and dozens of other commands, and provides a command history for interactive use.)






share|improve this answer















It's exactly your point 3. When a command does very little (echo is a good example) spawning a new process dominates the run time behavior. With growing disks and bandwidth and code bases you always reach a spot when you have so much data and so many files (our code base at work has 100k files!!) that one less spawn per file makes a difference of minutes.



That's also why the typical built-in is a drop-in replacement which takes (perhaps a superset of) the same arguments as the binary.



You also ask why the old binary is still retained even though bash has it as a built-in — the answer is that a lot of programs rely on the existence of that /bin/echo. It's actually standardized.



The bash is only one of many user interfaces and offline command interpreters. They all have different sets of built-ins. Some shells are purposefully small and rely a lot on what you could call "legacy" binaries. One example is ash and its successor, dash. dash is now the default /bin/sh in Ubuntu and Debian due to its speed, and is popular for embedded systems due to its small size. (But even dash has builtins for echo, test and dozens of other commands, and provides a command history for interactive use.)







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 19 '18 at 11:52

























answered Nov 18 '18 at 20:11









Peter A. SchneiderPeter A. Schneider

9,3812142




9,3812142













  • But why not have it only as an internal command then, like cd? What's the purpose of making it external as well?

    – Marko Cain
    Nov 18 '18 at 20:13













  • @MarkoCain Oh.... I'll answer that in the post.

    – Peter A. Schneider
    Nov 18 '18 at 20:14











  • Fedora (and RHEL?) does have an external /bin/cd script which simply calls the /bin/sh builtin cd command. It's only purpose, as far as I can tell, is to check whether a "cd" command will succeed, without actually changing directories in the current shell.

    – simon3270
    Nov 20 '18 at 11:03



















  • But why not have it only as an internal command then, like cd? What's the purpose of making it external as well?

    – Marko Cain
    Nov 18 '18 at 20:13













  • @MarkoCain Oh.... I'll answer that in the post.

    – Peter A. Schneider
    Nov 18 '18 at 20:14











  • Fedora (and RHEL?) does have an external /bin/cd script which simply calls the /bin/sh builtin cd command. It's only purpose, as far as I can tell, is to check whether a "cd" command will succeed, without actually changing directories in the current shell.

    – simon3270
    Nov 20 '18 at 11:03

















But why not have it only as an internal command then, like cd? What's the purpose of making it external as well?

– Marko Cain
Nov 18 '18 at 20:13







But why not have it only as an internal command then, like cd? What's the purpose of making it external as well?

– Marko Cain
Nov 18 '18 at 20:13















@MarkoCain Oh.... I'll answer that in the post.

– Peter A. Schneider
Nov 18 '18 at 20:14





@MarkoCain Oh.... I'll answer that in the post.

– Peter A. Schneider
Nov 18 '18 at 20:14













Fedora (and RHEL?) does have an external /bin/cd script which simply calls the /bin/sh builtin cd command. It's only purpose, as far as I can tell, is to check whether a "cd" command will succeed, without actually changing directories in the current shell.

– simon3270
Nov 20 '18 at 11:03





Fedora (and RHEL?) does have an external /bin/cd script which simply calls the /bin/sh builtin cd command. It's only purpose, as far as I can tell, is to check whether a "cd" command will succeed, without actually changing directories in the current shell.

– simon3270
Nov 20 '18 at 11:03




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • 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%2fstackoverflow.com%2fquestions%2f53364895%2fwhy-are-some-bash-commands-both-built-in-and-external%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







-

這個網誌中的熱門文章

Xamarin.form Move up view when keyboard appear

圖片
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box; } 0 I'm trying to build a Chat app UI, the idea of the Layout was pretty simple: When the input bar is focused, keyboard show up and "push" up the chat bar, as it's a grid, the ListView will resize to fit the screen: I update the input bar's margin to "push" it up: NSValue result = (NSValue)args.Notification.UserInfo.ObjectForKey(new NSString(UIKeyboard.FrameEndUserInfoKey)); CGSize keyboardSize = result.RectangleFValue.Size; if (Element != null){ Element.Margin = new Thickness(0, 0, 0,keyboardSize.Height); //push the entry up to keyboard height when keyboard is activated } And this is ...
閱讀完整內容

Post-Redirect-Get with Spring WebFlux and Thymeleaf

圖片
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box; } 2 Can someone explain to me how to implement the post-redirect-get pattern in Spring WebFlux and Thymeleaf? What subscribes on the database save method? @GetMapping("/register") public String showRegisterForm(Model model) { model.addAttribute("user", new User()); return "register"; } @PostMapping public String processRegisterForm(@Valid User user, BindingResult bindingResult) { if (bindingResult.hasErrors()) { return "register"; } else { userRepository.save(user); //what subscribes on this? //how to redirect on e.g. "/login"? ...
閱讀完整內容

Anylogic : not able to use stopDelay()

圖片
-2 I am building a railway station model. I want a train to depart when I click a button. I want to call stopDelay() for that but I am not sure how to do that and from which place. anylogic share | improve this question asked Nov 23 '18 at 10:12 Anupam Singh Anupam Singh 1 Hi Anupam, welcome to SOF. Please check how to ask good questions, see link below. Your question is...
閱讀完整內容