Probably not but you can only judge a language when you've written lot of code in it. If you write large non-trivial programs in ― for example ― bash, you'll only have to look up bash.1 so many times after which you just absorb it. Then you'll see how things click together and you don't need the manual much after that.

I like bash. Especially bash v4 brought some niceties, making it even more suitable for various non-trivial tasks.

I generally don't "upgrade" to Python or some "real" scripting language unless I really have to: bash is surprisingly concise and expressive. I've written programs and subroutines in bash that were much smaller than their idiomatic Python counterparts and I was surprised to discover that.

Bash is conceptually pretty safe and suits the functional mindset because in a large program you find you want to isolate each function the Unix way: byte streams. You pass in a stream (and args) and you get a stream out (and exit status). Thus, you end up making the functions quite pure and well off if you come from a functional background. Pure functions/shell scripts are rather safe and also parallelize pretty well.

If part of your program does something critical it's best to move it from a set of functions into a separate shell script. This gives you the same Unix stream API but also the benefit of process-level separation of data and environment. It simply enforces the Unix byte streams as the only way to talk between the caller and the callee.

And usually you can do this with only a few lines of code. Shell scripting can be ― and is ― intuitive. This is because processing files and streams, I/O, and parsing and mangling command lines and strings of words is pretty implicit in bash, which usually is very close to what you want to achieve in the end so you get down to the actual work pretty quick.

That's probably because most people only sporadically have to write shellscripts. If you had to write it every day, I bet you wouldn't have that problem.

Having said that, I personally don't feel shellscripting is all that intuitive either.

As soon as my shellscripts need control structures, I jump to a "real" language like Perl or Python.

Haven't used it much, but I find Fish shell control structures much more consistent that those in *sh: http://fishshell.org/

Indeed -- that's where Perl still fits into my day-to-day toolbox. It's exactly in those 5-50-liners with a little logic that I want a language with an overabundance of syntactic shortcuts. Shell is the exact opposite of that.

> That's probably because most people only sporadically have to write shellscripts.

Does anyone have to write shellscripts? If I'm writing one and it has any degree of complexity at all -- i.e. has loops or subroutines -- I just write it in Python. The only part of bash I know is the subset I use interactively on the command line.

Agreed. The only reason I've had to learn any 'real' shell is to write portable init scripts. That being said, I'd probably rather write init scripts in ruby or python anyway.

Besides, init scripts aren't really portable (across distros) to start with, ubuntu/debian scripts rely on start-stop-daemon and a specific filesystem layout. The use of shell for init scripts is probably only useful because using dash (/bin/sh) to execute them is likely faster than using a fancier language (though I haven't benchmarked this).

BTW, ever try and write anything non-trivial using dash (POSIX shell features only). It's pretty painful. Lots of people mistakenly write shell using non-posix (bash) features, and are unpleasantly surprised when /bin/sh links to dash, thus breaking their scripts.

I've written large scripts in bash (using range ellipses, arrays, /dev/tcp, arithmetic shells, nested subshells, IFS changing & $@ to handle filenames with spaces, etc) as part of writing kickstart scripts, RPM install / update scripts, and initscripts.

I'm also familiar with object pipelining shells from using powershell.

ANI looks like an unreadable mess to me.

I write maybe one or two ad-hoc shell scripts every day, many only for a single use. Bash isn't so bad once you get used to it. Things like Perl, Python or Ruby are often less suited owing to lack of parallelism or scalability without more effort than I'm willing to spend, as I typically write the scripts in 2 or 3 minutes or so. Most of my scripts are pipes of other utilities, written in a streaming style, often with multiple forks writing to temporary files and joining with a sort at the end.

I wouldn't feel the same way if it was a different sh than bash. For example, this is easy in bash:

    let total=0
    let n=10
    for ((i=0; i<n; ++i)); do
       if (( i % 2 != 0 )); then
           printf 'Odd: %.3d\n' $i
       fi
       let total+=i
    done
    echo "Total is: $total, average is $((total / n))"

Staying inside bash, you only have integer arithmetic, but that's sufficient for many problems. The major advantage is that you can easily, and more importantly, readably, compose solutions using programs written in dozens of different languages. The syntax for piping programs together in scripting languages tends to be imperative, rather than declarative like a shell script.

The placing of those semicolons inside control structures gets me every time.

I just don't do enough of it to make it in to an automatism.

You don't need the semicolons if you prefer newlines. e.g.

   let total=0     
   let n=10    
   for ((i=0; i<n; ++i))  
   do  
       if (( i % 2 != 0 ))  
       then printf 'Odd: %.3d\n' $i  
       fi  
       let total+=i  
   done  
   echo "Total is: $total, average is $((total / n))"

I know zsh has extremely good manpages, even for things like control structures (try zshmisc(1)), and it describes a lot of the differences between itself and bash or restricted sh syntax.