I love when people attempt to help others. But so often the content is so wrong (or old) that it does more harm than good. For the most part https://www.shellscript.sh gets most things right, but here are some very glaring omissions, enough omissions, in fact, to make it something I would strongly discourage anyone from looking at at all because of the bad habits it might instill.
(surprised no mention of https://linuxcommand.org)
There are several excellent resources available for learning POSIX shell scripting:
Bash Guide for Beginners: This comprehensive guide provides a solid foundation in POSIX shell scripting, covering a wide range of topics from basic commands to advanced scripting techniques. It offers clear explanations and practical examples to help you master shell scripting. You can find it here http://tldp.org/LDP/Bash-Beginners-Guide/html/.
Advanced Bash-Scripting Guide: Building upon the fundamentals, this guide delves into more advanced concepts and techniques, making it an excellent resource for experienced shell scripters. It covers topics such as process management, debugging, and error handling. You can access it here http://tldp.org/LDP/abs/html/.
The Linux Documentation Project: This project hosts a vast collection of guides and how-tos, including various tutorials and examples on POSIX shell scripting. You can explore their extensive documentation here http://tldp.org/.
ShellCheck: While not a comprehensive learning resource, ShellCheck is an essential tool for any shell scripter. It identifies and suggests improvements for common issues and pitfalls in shell scripts. You can use it interactively on their website here https://www.shellcheck.net/ or install it locally on your system.
These resources should provide you with ample material to get started with POSIX shell scripting and improve your skills over time. Happy scripting!
This prevents them from being replaced with other code later. Besides, it is definitely not following the UNIX philosophy (which the author makes a rather big deal about at the beginning.
shellcheck and learn from itThere’s not a better resource for learning shell programming than the most important validation tool ever made for shell scripting.
Yes, I’m gonna say RTFM. The manual always has more and doing one’s own experimentation (instead of watching someone else’s) is a much better way to learn.
Everyone who actually knows how to code well in shell uses the safer and nestable $() syntax instead of backticks. The nestable syntax even has multiple quote contexts allowing each to contain both double and single quotes just as if they were on the same line. Only an absolute shell noob would recommend using backticks at all. They are only something people should use when doing things from the command line itself as a shortcut, never, ever anything to put into code where they are virtually impossible to read as well. But, then again, if this author even knew about shellcheck they would have caught that, but they don’t know about it because they are yet another noob producing books without actually learning it first.
Pretty much everything in there is just horrible. Just run any of those examples through shellcheck to see for yourself.
When the conversation about “variable scope” happens it doesn’t bother to draw the contrast with ksh and bash (which do have local variable scoping). This could leave readers thinking their only option is globals for everything.
There is no need in 2023 to use expr for anything. Research why to find out. Here’s what ChatGPT has to say about it:
Using expr in shell scripts is considered bad practice for several reasons:
Limited functionality: expr is limited in terms of the mathematical operations it supports. It can only handle basic arithmetic operations like addition, subtraction, multiplication, and division. Complex mathematical operations and functions are not supported.
Lack of error handling: expr does not provide robust error handling. If any errors occur during evaluation, it often fails silently or produces unexpected results. This makes it difficult to debug and can lead to incorrect script behavior.
String handling limitations: expr is primarily designed for numeric operations and has limited capabilities for string manipulation. It cannot handle advanced string operations, including string concatenation, substring extraction, or regular expression matching.
Limited portability: Although expr is a standard Unix command, its syntax and behavior may vary between different platforms. This can cause compatibility issues when running scripts on different operating systems or shell environments.
Instead of expr , it is recommended to use more modern and versatile alternatives like the built-in arithmetic expansion $((...)) , command substitution, or external tools like bc or awk. These alternatives provide better error handling, support complex mathematical and string operations, and offer improved portability across different environments.
This would have been much better as a command that could be executed from a tmux window or pane.
This proves this content is not only bad, but old.
The assumption is that you just know them, but this is the single biggest source of confusion for beginners.
telnetNothing screams “I was written in 1994” more than a reference to telnet at all.