But it sure isn't that much more complex nor requires a lot more of your system, so I'd say it's more a matter of preference.
To write your workflow purely in shell scripts, you will invariably use lots of tests.
Also note that they are not necessarily mutually exclusive. You can write Makefiles that call shell scripts (and shell scripts that call make)
SHELL=/bin/bash
at the top of the Makefile when I use bashisms to construct complex pipelines.
And once, in a fit of mad genius, I made a particularly complex and useful Makefile executable by putting #!/usr/bin/make -f at the top. (It was a bad idea, obviously, and I won't be doing that again.)
For large file based datasets, the shell is just a REPL.
- straightforward and obvious support for multiple named entry points
- by default, process terminates when a command returns a non-0 exit code
- often-adequate (though still crappy, especially for paths with spaces) set of built-in string processing functions
- scripts often somewhat portable between Unix-style shells and Windows
(I suppose there may be Unix-style shells available for Windows, but I've never found a low-dependency one that actually works. So combined with the first three advantages I've stuck with make.)
I've actually found Make much better as a shell script replacement than it is for its stated purpose of building software :)
Imagine that you needed to download a tar archive, unpack it, then run several simulations followed by regressions followed by figure plotting on the data. You could write a shell script to do this, but it would be hard to make the shell script simulate the capabilities of `make -j', and you'd have to do a lot of timestamping and file existence checking to simulate the incremental computation capabilities of make.