Makefiles make me feel the same way, but here I have little choice. You can structure them "well" but they remain essentially undebuggable bits of hell that always seem to fall apart at the worst time.
I've worked with systems that had multi-thousand-line batch files and shell scripts, and my reaction has been "this crap is unsalvageable". A lot of those systems are still in production, and the people on them hate their lives. The code is a mass of spaghetti with a bunch of behavior modified by global and environment variables.
About 30 years ago I made the statement that "BASIC programs should self-destruct after 50 edits", as a way to encourage users of that language to move on to something more better, and to limit the damage that a "mission critical" 2 KSLOC hunk of bad code incurs. I maintain this would be desirable for bash and batch-like stuff, too...
I agree that the surface syntax is bad. Unlike other languages with clear Algol influences it never got past thinking writing if backwards to end the block is clever. I'm all for fixing these sorts of things, if you're going to break compatibility with posix anyways.
Also, you miss one particularly elegant aspect of shell programming: the pipeline. It's a powerful facility of concatenative programming, but most people haven't realize it. Try to write "find . -name '*.py' | xargs cat | wc -l" in other languages. You end up either with some parentheses or intermediate variables or a loop, and in any case, much longer code.
Even erlang can be a shell and wrap around the system toolset making your basic shell scripts work concurrently.
For everyday usage the core ash shell is perfect for scripting and zsh csh or korn for interactive usage.
In my experience, most people have great difficulty correctly writing a simple loop to renames a set of files in a directory. I sumultaneously appreciate UNIX philosophy, and think the shell can be much improved by moving away from POSIX.
This is where some of the warts on a higher level than syntax come in, though, to be fair. Your example above fails in confusing -- and maybe even dangerous, depending on the command at the end -- ways if there's spaces in the filenames. One thing I would like would be a more rigid sense of arguments vs. strings and how they come out of such situations. Having to add -print0 to find and --null to xargs to make it safe for that situation is tedious and unfriendly.
Yes, that's one of the problems I'm trying to solve :)
Powershell solves this by having pipelines pass .NET objects, but I found them too heavyweight.
Here's a comparison of code to do the same thing written in Ruby:
Dir['**/*.py'].map{|f| File.readlines(f).length }.inject(:+)
find . -name '*.py' | xargs cat | wc -l
I ran them on Python 2.7's library directory and my version counted four lines more – I didn't investigate, but I think yours missed lines when cating files without trailing newline. I'd argue that's a bug in your code :)
xs.filter(p).map(f)
filter p xs | map f
map f $ filter p xs
xs # filter p # map f
filter p xs # map f
import pipe
find(name='*.py') | xargs(cat) | wc().lines
This is kind of the point.
Languages are not only about what they make possible, but also about what they encourage.
It is quite primitive as languages go, though, and has some ugly quirks, but I think it's a mistake to look at it and say it needs to be changed to be more like things not designed to treat running programs as primitives. I'd rather see something from someone who said "bash is great but could be so much better!" than someone who said "bash is TEERRRRRUUUBLE and we must replace it!"
That said what I want so much more than a new shell is one that isn't stuck letting me only reason about the machine I'm logged in on. There's been a few things that call themselves distributed shells, but they're really more orchestration tools.