Linked article is actually a really horrible intro to bash -- at best, it is an OK intro to pre-POSIX bourne shell scripting.
Specifically:
* test and [ ] are fraught with parameter expansion peril. Use [[ ]] instead.
* The author uses single quotes around strings that are demonstrating parameter expansion. Single quotes inhibit parameter expansion, so every one of those examples is wrong.
* select is a better tool than read; case for most of his case-relasted demos.
Whoever made the guide is unexperienced in the tasks he writes about. Otherwise he'd know about [[ and ((. Were it an intro for non-bash shells, it would be an acceptable omission. And you're not really explaining how to write conditions if you aren't explaining this:
Actually POSIX does not recognize double brackets [1]:
"The KornShell-derived conditional command (double bracket [[]]) was removed from the shell command language description in an early proposal. Objections were raised that the real problem is misuse of the test command ( [), and putting it into the shell is the wrong way to fix the problem. Instead, proper documentation and a new shell reserved word ( !) are sufficient."
The entire section on test is full of advice on the proper use of test(1).
I replied to a specific comment, not to the article. In particular, nescafe said this was "an OK intro to pre-POSIX bourne shell scripting". I took this to mean that he would provide POSIX-endorsed suggestions. The double brackets, at least, are not "post-POSIX".
grumbling guy with beard walks by, mumbles "Here's a dollar kid, get yourself a real font." And walks on...
Unless your shell and editor are displaying in courier, or you use extremely small glyphs (I've seen folks doing terrible things to their font scaling on 100dpi mac screens trying to get more lines on the screen) that should not be a problem. Certainly the Vera Mono font family gets this right; a backtick is quite distinct.
Although to further nitpick, your proposed substitution doesn't quite do the same thing, since it searches every directory below the pwd, rather than what's in the pwd.
Agreed on quoting.
for file in *.java; do javac "$file"; done
I'd also like to see something on substitutions which I find useful, like:
for file in quad_{upper,middle,lower}_{left,centre,right}.dat; do echo "$file"; done
I'd throw in a line or two about the difference between sourcing and executing a shell script, too. Not that this is sh-specific, but I often encounter folks who don't know how they're different, or why, and are perplexed by the behaviour.
Correct about the depth issue. Most find versiosn will present an option to do this, although different versions have different syntaxes (-maxdepth 1 for GNU find, -prune for Solaris).
Agreed on the difference between sourcing and executing. I would say in general it would be beneficial to include a paragraph on which code is executed in the current process and which will fork a new one.
This would avoid errors on the files with whitespaces, however it will also avoid compiling them. You cannot make the assumption that a file with a whitespace should not be compiled.
Incorrect. Word splitting does not happen in [[ ]] tests. The only reason I had the [[ -f $file ]] || continue is to handle the case where there are no .java files, which will cause the for loop to iterate once with file set to '*.java'. i could have also used nullglob,but chose not to.
No it won't, [[ -f $file ]] will fail and `continue` will be executed, moving on to the next iteration of the loop. Think of the different successive values the $file variable will have. At no point, will it hold the full name of the file at once.
What if "*.java" expands to something too large? Or is that only a relevant concern on the command line itself ("Argument list too long" error) and not within a script?
Thank you! I've been looking for a condensed yet thorough overview of bash for quite some time. I use bash only sporadically and I am never successful when googling easy things like how to test for equality of numbers.
I suppose that if one were a Bash God, as being any other sort of God, "one day is as a thousand years, and one thousand years is as a day." This implies that you routinely underestimate time by a factor of 365 250. That number of seconds would be about 4.2 days, so to a Bash God, 10 seconds is as 42 days.
42 days is I guess a reasonable estimate for learning Bash if you're really new and coming from Windows -- but perhaps it's a little too much; you could probably get fluent in two weeks if you really focused and already knew the basics of programming.
So the Bash Gods should clearly revise the number down to three seconds.
Specifically:
* test and [ ] are fraught with parameter expansion peril. Use [[ ]] instead.
* The author uses single quotes around strings that are demonstrating parameter expansion. Single quotes inhibit parameter expansion, so every one of those examples is wrong.
* select is a better tool than read; case for most of his case-relasted demos.
* Backticks ( ` ` ) are the devil.
At least he points people greg's wiki at the end.