I don't think anyone would argue that BASH provides a good scripting environment. It provides a commonly available scripting environment that even its successor shells attempt to emulate. But it's idiosyncratic, at best, and leads to bug-prone scripts.

But there are certain tasks that it excels at- specifically, the kinds of tasks that you'd normally do from the shell but just want to wrap some light automation around. Want to scan a directory and then copy some subset of the files out based on user arguments? BASH is your friend! It's just some basic conditionals and some cp commands, what could be easier?

Well, I'm not sure, but Radu's predecessors found a way to make it harder. Because they didn't use the cp command anywhere. ANd why should they? I mean, look at the flags documented on the man page: cp [-R [-H | -L | -P]] [-fi | -n] [-alpSsvXx]? Who wants to learn all of that? They certainly didn't.

Whenever they needed to copy files in a script, they did this instead:

cat mySourceFile > myDestFile

cat, of course, is short for "this is actually concatenation, but everyone uses it to dump files to STDOUT", which is how it's being used here. And then they just redirect the output to the destination file. Which… works, ish. It's certainly the worst imaginable way to copy, with a huge pile of overhead that avoids leveraging any filesystem level optimizations. And I'm sure that there are input files for which this will break.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!