And yet, the top search result is tldp. This is what #bash on freenode has to say about that site:
> The infamous "Advanced" Bash Scripting Guide should be avoided unless you know how to filter out the junk. It will teach you to write bugs, not scripts. In that light, the BashGuide was written: http://mywiki.wooledge.org/BashGuide
Now, that site is on the second "page" of the search results.
Well for example, I just skimmed through it and I don't see an explanation of quoting, probably one of the first things I would want to explain, around the time variables are explained. It also has examples like this:
#!/bin/bash
for i in $( ls ); do
echo item: $i
done
which both uselessly calls ls (you may as well just use a glob) and doesn't work as intended if there are filenames with spaces in the directory.
You also have:
#!/bin/bash
for i in `seq 1 10`;
do
echo $i
done
Why is it using backticks here instead of $() as in thr former example? Also, no mention that seq is not available on some systems. And, you should be using bash's sequence expression[1] anyway (added in bash 4.x), so the guide is likely out of date.
Using ls instead of a glob can be valid if you need to force ordering for some reason (you want to process things in date order for instance, IIRC the order out of a glob wildcard is alphanumeric in most places and arbitrary in some). Your point about spaces in filenames is definitely valid though but my preferred solution to that would be to stab people with a needle every time they put a space in a filename!
There are a great many things on the command line (less elsewhere, but still some) that don't handle spaces in filenames well.
You are probably right that this is a technological fault rather than a problem with spaces themselves, but IMnsHO until we are not regularly using spaces as list item separators using them with the items being listed is asking for issues.
You can easily deal with spaces in bourne shell. Quote your variables. Change the IFS to make it only newlines. Of course, newlines in filenames are perfectly valid too.
I use some systems without seq, and they have Bash with version 2.x or 3.x on them (eg., OSX). seq has the nice property that writing a shell or executable replacement is easy.
I think the 2nd example is fine. It might be cut and pasted from a POSIX example.
The TLDP bash guide is full of a range of submitted examples that run the gamut of good and bad practices. That said, it's still one of the better resources out there, and I have the reference page bookmarked. But this is Bash we're talking about, "best" practice is a relative term.
> The infamous "Advanced" Bash Scripting Guide should be avoided unless you know how to filter out the junk. It will teach you to write bugs, not scripts. In that light, the BashGuide was written: http://mywiki.wooledge.org/BashGuide
Now, that site is on the second "page" of the search results.