Episode 8 - Unix Shell Builtins vs. External Commands Key concepts from this episode: - Demonstration of working interation between aliases, functions, shell builtins, and external commands. - Use of the type command to get an explanation of how bash resolves a given simple command. I actually covered most of this already in my comment from Episode 7. Rather that completely re-iterating everything from that comment, I'll instead give some errata here. 1. General errata. - The four command types Dave enumerated as possible resolutions by bash are the four categories of "simple command" that bash knows how to execute. You can get a single-word descriptor of which command type bash will resolve a word to by doing 'type -t '. See 'help type' for the possible answers. - Dave shows the 'which ' command as the best way to see which executable bash would execute out of $PATH. In my opinion this is very slightly cringe; modern bashes give 'type -P ' and 'type -Pa ', which respectively dump the first executable from $PATH matching the word, and all executables from $PATH, one per line. This doesn't just save a fork, it also benefits from cases where your current $PATH will change in the shell executed by the `which` command, which might not even be bash depending on your system. 2. alias errata. - 'shopt -s expand_aliases' is required to make aliases work inside your scripts. Without this, they only function in interactive shells. - \ (preceding a word with a bashslash) will bypass any alias corresponding to that word. 3. builtin errata. - Bash provides builtins called 'enable' and 'disable' which can be used to enable or disable certain bash builtins at runtime. If you want an executable to win out over a builtin with the same name, and don't want to give the path to the executable, disabling the builtin is one option. - Using enable, it's possible to load builtins that are not part of bash itself, via dynamic linking and the BASH_LOADABLES_PATH environment variable. If Dave ever gets to talking about this in YSAP, I probably won't comment because that's way out of my depth, but Googling on the subject just now you can apparently write the builtins in Rust using a crate called bash_builtins. That might scratch some of you in spots you didn't know you were itching. - Bash documentation divides builtins into two broad categories, 'bash builtins' and 'bourne shell builtins'. It's worth educating yourself as to which is which. Unixes with non-bash shells get more and more rare but you do still occasionally encounter them, especially if you work with embedded systems and rackable appliances. The best place to read about the differences between these is in the Bash Reference Manual, which you can find at www.gnu.org/software/bash/manual/bash.html or by running 'info bash' on many bash installations. (Chapter 4 as of this writing.) - Also slightly cringe in Dave's example, he wants to access the echo builtin from inside a function but does this with 'command' which can match either a builtin or an external command, instead of using 'builtin' which explicitly resolves to a builtin. External commands and functions are both going to be covered more in later episodes so I'll skip errata for those for today. Happy scripting!
Episode 8 - Unix Shell Builtins vs. External Commands
Key concepts from this episode:
- Demonstration of working interation between aliases, functions, shell builtins, and external commands.
- Use of the type command to get an explanation of how bash resolves a given simple command.
I actually covered most of this already in my comment from Episode 7. Rather that completely re-iterating everything from that comment, I'll instead give some errata here.
1. General errata.
- The four command types Dave enumerated as possible resolutions by bash are the four categories of "simple command" that bash knows how to execute. You can get a single-word descriptor of which command type bash will resolve a word to by doing 'type -t '. See 'help type' for the possible answers.
- Dave shows the 'which ' command as the best way to see which executable bash would execute out of $PATH. In my opinion this is very slightly cringe; modern bashes give 'type -P ' and 'type -Pa ', which respectively dump the first executable from $PATH matching the word, and all executables from $PATH, one per line. This doesn't just save a fork, it also benefits from cases where your current $PATH will change in the shell executed by the `which` command, which might not even be bash depending on your system.
2. alias errata.
- 'shopt -s expand_aliases' is required to make aliases work inside your scripts. Without this, they only function in interactive shells.
- \ (preceding a word with a bashslash) will bypass any alias corresponding to that word.
3. builtin errata.
- Bash provides builtins called 'enable' and 'disable' which can be used to enable or disable certain bash builtins at runtime. If you want an executable to win out over a builtin with the same name, and don't want to give the path to the executable, disabling the builtin is one option.
- Using enable, it's possible to load builtins that are not part of bash itself, via dynamic linking and the BASH_LOADABLES_PATH environment variable. If Dave ever gets to talking about this in YSAP, I probably won't comment because that's way out of my depth, but Googling on the subject just now you can apparently write the builtins in Rust using a crate called bash_builtins. That might scratch some of you in spots you didn't know you were itching.
- Bash documentation divides builtins into two broad categories, 'bash builtins' and 'bourne shell builtins'. It's worth educating yourself as to which is which. Unixes with non-bash shells get more and more rare but you do still occasionally encounter them, especially if you work with embedded systems and rackable appliances. The best place to read about the differences between these is in the Bash Reference Manual, which you can find at www.gnu.org/software/bash/manual/bash.html or by running 'info bash' on many bash installations. (Chapter 4 as of this writing.)
- Also slightly cringe in Dave's example, he wants to access the echo builtin from inside a function but does this with 'command' which can match either a builtin or an external command, instead of using 'builtin' which explicitly resolves to a builtin.
External commands and functions are both going to be covered more in later episodes so I'll skip errata for those for today. Happy scripting!
Hi, I wanted to read #7 comment but it's not there
Really nice channel, and the vids are very concise so I don't mind sending them to co workers who are new to Linux, thank you!
Huh, that was super cool! Loving the vids.
You had me at hello world
Fantastic explanation and tutorial!
Great video. Been using the terminal for a while and didn't know this.
Damn I have an exam where this will be asked , really thanks bro.
that’s awesome that you’re learning bash in your studies #bash #programminglanguage
ok I just realized something
i suck at programming
What about ansi macros? That makes things even more complicated... or is it fun?
how are you getting away without using quotes or escape with echoing hello world with space between them?
`echo` takes multiple arguments and each will be separated by a 'space' by the echo program.
these videos are too based. 10k subs by the end of the year calling it now
the terminal is your friend #bash #programminglanguage #unix
So why do all these builtins exist? Is it because they’re faster than the bin equivalents?
And they don't require a new process, there's an example in one of the other videos
Yo my name is Razo and i suck at programming