>If your shell script starts with #!/bin/bash or #!/bin/ksh93, you should use [[ ]] syntax -- it is in general faster and more flexible than the test command (which is what you are actually using when you use single square brackets).
Still don't know what the difference is though. The bash manual is not especially enlightening in this area (NB. if I really cared I would Google it, of course)
>If there is any doubt, read the fine man page for the shell you are targeting. The bash man page is quite thorough -- I recommend having it open as a reference when coding in bash.
Thorough, no doubt. Not especially useful however - unless you know precisely what to search for, finding a needle in that haystack is almost never worth the time when Google is available. The dash manpage is slightly less unwieldy, as one might expect.
Still, this seems to prove the point rather well - what other languages require you to keep the documentation open constantly due to unintuitive and inconsistent choices in basic syntax?
I'm not saying that shell scripting is absolutely intolerably awful, just that it tends to make easy things hard. For scripts that don't need specific features like setting traps or atomic lockfile creation, it's much less painful to use, say, Lua. Or Python if speed is of no account.
Posted May 6, 2010 17:12 UTC (Thu) by nescafe (subscriber, #45063)
[Link]
>>If your shell script starts with #!/bin/bash or #!/bin/ksh93, you should use [[ ]] syntax -- it is in general faster and more flexible than the test command (which is what you are actually using when you use single square brackets).
>Still don't know what the difference is though. The bash manual is not especially enlightening in this area (NB. if I really cared I would Google it, of course)
[[ ]] is syntax, [ ] and test are (builtin) commands. [[ ]] does not perform word splitting or pathname expansion on its arguments (no more quoting "just because", and you can use bash's builtin regex support (and get rid alot of trivial uses of sed and awk). The manpage goes into more detail.
>Still, this seems to prove the point rather well - what other languages require you to keep the documentation open constantly due to unintuitive and inconsistent choices in basic syntax?