C vs Bash (Bourne-Again SHell)

Undefined behavior in a program can cause unexpected results, making it hard to debug. With UB, program behavior may vary wildly depending on optimization settings. There are many cases that invoke UB, such as signed overflow, invalid dereferences, large integer shifts, uninitialized variables, etc. These serve to frustrate novice programmers when they could be learning other concepts.

Learning programming is already hard enough when you don't have to worry about memory leaks.

The C standard library is not type safe, and the language itself does not promote type safety built into the language, which leads to error-proneness of the language. If anything, it would be recommended that those interested in C to instead put their time in D, which actually includes a complete copy of the C standard library rewritten to be fully type safe.

While other programmers will learn algorithms and structures and will do magic tricks and awesome applications, you will learn trash info that you should know maybe after 5-7 years experience in software development, not earlier. It's like going the first time as a seven year old kid to first school class, and your teacher tells you to learn you about Discrete Math, without basic math and how to do 2x2.

If you wish to be a really good programmer, C for sure will be in your portfolio, but not as a first language, and this programming language is used only for very hard and very limited tools which require a lot of professional skills from the programmer.

Header files are a poor man's implementation of modules. Modern programming languages make use of modules which eliminate the need for C includes and header files and the many issues caused by them, such as the complete lack of dependency checking. Header files often contain even more include statements that point to other header files which also point to even more which drastically increases compile time. Modules only have to be compiled once, and when importing those modules into your software project, you only have to pull in the module that you are using, which is often times already precompiled. This way, the compiler knows exactly what it needs before beginning to compile your project and can automatically compile the few dependencies it needs in advance rather than recursively compiling every header file it runs across as in C.

While the language compliments knowledge of computer components very well, and gives a deeper understanding, it is also quite difficult to learn, and to use correctly, especially without aforementioned knowledge.

Depending on the purpose this can be either a pro or a con. If the task is to learn how to program, low-level of C will impend learning important concepts. Furthermore, C is rather limited in ways of building abstractions.

"Low-levelness" of C can be a pro feature in learning system programming.

There are languages like Rust, Object Pascal, D, Golang, Vlang, Odin, Zig, Jai, etc... that can be used instead. The other languages are easier to understand, use, and/or about as fast.

In the same manner that C recursively compiles header files ad infinitum without any sort of dependency checking, C source code is also compiled in the same manner. If you attempt to call a function before it is declared, the compiler will fail because the function was not compiled before it was caled.

C does not support the string type, nor does it support UTF-8 strings that modern languages are employing today. Instead of strings, C makes use of the *char type which is a pointer to a character array.

When an array is passed to a function, it is converted to a pointer, even though the prototype confusingly says it's an array. When this conversion happens, all array type information gets lost. C arrays also cannot not be resized, which means that even simple aggregates like a stack are complicated to implement. C arrays also cannot be bounds checked, because they don't know what the array bounds are.

Subtle errors can render the entire program "undefined" by the complicated C standard. The standard imposes no requirements in such cases. Thus C compiler is free to ignore the existence of such cases and Bad Things are prone to happen instead. Even experts can't reliably avoid undefined cases in C, so how can beginners be expected to do so? C allows for non-type safe operations such as logic errors, wild pointers, buffer overflow, etc. UB and type safety issues create a large number of bugs and security vulnerabilities.

Older languages, like C, are no longer in their hay day. Even if you do learn it as your first language, you are only setting yourself up to need to learn another language in the long run. If you want a skill that you can not only learn from, but also potentially build a career on, C should not be your first choice.

The C programming language is not portable to other operating systems, and even different compilers, because the C language does not provide any reference cross platform libraries or compilers. Different platforms and compilers provide their own implementation of the C standard library which may not be compatible with the implementation in another compiler or platform. Without cross platform libraries and tools, one cannot state that C is portable. This is in stark contrast to modern programming languages that provide their own cross platform libraries and compilers, such as D, Go and Rust.

Modern programming languages are capable of compiling split source code files by concatenating them together efficiently at compile time before compiling them. However, C requires the developer to resort to messing with header files and makefiles to get similar functionality.

C structs lack a lot of modern capabilities that are vital in programming languages of today, such as assigning member functions to structs to give them object-oriented capabilities, constructs, deconstructors and RAII. Great care must be used when using structs in C to prevent memory leaks and ridiculously slow structs.

All the modern languages have resulted in ditching the ancient deprecated model of #include statements and have instead adopted the superior model of modules. When compiling software written in C, the programmer is forced to also compile X headers which contain Y headers which contain Z headers and so forth -- drastically increasing the number of lines that need to be compiled. In order to compile something as simple as "Hello, World", for example, 18K lines of code needs to be compiled. This can be very taxing on RAM and CPU resources, causing compile times to quickly absorb a large portion of the programming process.

C lacks a large majority of programming concepts that modern languages make use of today. The existing functionality of C makes use of outdated and deprecated methodologies which can be of great annoyance to the modern day programmer.

In Bash, exceptions are the rule, not even all being described by the main page.

There are a grand total of 5 different ways of quoting, sometimes even when one does not want to, for instance in command substitutions. These are all based around preserving the literal meaning of every character, with an exception list. There is even an exception list to the exception list in 4 of the 5, regarding how the backslash behaves! The behavior of the backslash is also one of the quoting rules, so naturally, it also has an exception in how it works when it stands before a newline as compared to other characters.

Bash has several layers of interpretations, all to be kept in mind:

The ~ expands to the home of the current user. So if you store it in a variable, can you use it that way? Nope: tilde expansion comes before variable expansion.

Aha, so that's how it works! Then, since applying quotation happens after redirections are set up, it must mean that redirecting within quotes works, right? Nope: there is an exception! If a redirection symbol is not quoted, quotation around the symbol is observed, but is not removed. So, since variable expansion also comes after setting up redirections, and no exceptions are described here in the man page, getting the name of a file from a variable and using it as a target should not work, right? No: redirection does not actually take place when the symbols are being read, the symbols are merely removed and are noted for later, right before when the actual command runs.

Apart from 5 types of quotation, there are basically 2 quoting phases, 2 word splitting phases (with only one being controllable), and a tokenization phase on top of that.

If you have a command, it could be an alias, a special built in, a non-special built in, a symbolic link to a file, a regular file, a function, with different rules regarding how they can be overridden, if redirection happens before or after arguments have been passed (what does "time my_command 2>&1 >log_file" do?), etc.

This list is admittedly long, but it doesn't even scratch the surface of the bloat, complexity and inconsistencies of Bash.

Apple, one of the largest distributors of UNIX systems, only ships an ancient version of bash that predates the iPhone.

No one knows why as Apple hasn't said, but the version Apple includes in MacOS is from right before the license was updated to version 3 of the GNU GPL (General Public License). Other major companies (IBM, Microsoft) have had no problem shipping the latest version of bash, so it's unclear what Apple's lawyers are averse to. The GPL has always said that if you distributed a program, you granted everyone the right to use it freely. The biggest change in version 3 was the addition, "...and that includes software patents."

This was necessary because back in 2006 Microsoft was demanding that any company that uses Linux pay them or get sued for infringing on their patents. They even took some companies, like TomTom, to court. No software which can be restricted retroactively like that is truly free, so GPL 3+ includes a clause saying that if you distribute the program, then you are also granting license to any patents you own that are necessary to run it.

What patents Apple has that bash could possibly infringe on is a mystery, but the bigger question is, Why does Apple even care? So what if they are granting people the right to run bash without being sued by Apple. It's not like they were planning on doing that, right?

Even though it is not bash's fault that it is not Apple Lawyer-approved, this is a CON for it because a lot of people use Apple products. While there are methods like brew to install a current version of bash, Apple does not make it obvious to their customers what they are missing.

One of bash's claims to fame is compatibility with previous versions of itself and historic shells. But, doing that means that new features are often written in tortured, awkward syntax that is not easy to learn. For example, bash uses the POSIX way of doing arithmetic: to add 5+3 you must put the numbers in double parentheses with a dollar sign at the start: x=$((5+3)). It is true that many shells suffer from this same CON, but since bash is such an important shell, it has less wiggleroom to ditch clunky ideas that might break existing scripts.

People who wants power features or to customize their shell experience use zsh or fish.

filename expansion is not consistent. "echo *" will print the names of the files in your current dir, if there are any... and will print "*" if there are none.

If there are no .sh files, this will print mask itself:

for filename in *.sh; do
    echo $filename
done

To have command autocompletion in bash you need to install third-party plug-ins.

What it is mostly used for are file system operations. Guess what it is bad at? Operating on files. It automatically splits and carries out filename expansion on every single string resulting from variable expansion and command substitution unless quoted, by default on whitespace, whilst spaces are very common in filenames.

Before that, it even does pathname expansion, so woe to anywone who does not want to actually operate on files, but has a globbing metacharacter stored anywhere in a variable.

This means what you store in a variable is not going to be what will ACTUALLY be accessed.

If an empty variable is unquoted, it disappears completely due to word splitting, sometimes leading to applications signalling a missing parameter at a wrong position.

If quoted however, said variables cannot be iterated over in a loop, no matter what character one uses for word splitting.

If you use any globbing pattern with a command, be sure to use -- after the option arguments or if none are present, before starting the pattern with a mandatory ./

Otherwise, another Bash script run gone wrong or a hacker can create files named like an option ("-f", for instance) and your program will happily accept it as such, if it results from globbing.

For interactive use, it is convenient. For programming, it is a no-go.