Reminds me of my rather memorable introduction to special characters invoking functions, seeing this dastardly little quip in the email signature of someone in a mailing list (circa '95 or so).
:(){:|:&};:
My curiosity piqued, I pasted it into the shell on my terminal in a pure example of FAFO. The poor little Sparc 5 I was using ground to a halt over the course of about ten seconds. The reboot was as hard as the lesson. xD
In college I took a database class, it was pretty basic overall as I had been playing with MySQL for a few years at that point. On the final exam I got a 90/100. The test was 10 questions that just had you write SQL to answer the question. I got all the queries 100% correct... except... I didn't put a ";" after each query. On a written test. I'm still a little bitter about that.
The ultimately sad part was the professor in a Sun OS machine.
In a corner with no where to go, giving demerits because his bash was older than he realized.
Reminds me of my college professor that claimed you don’t have to close HTML tags (some you absolutely do) and I proved that you do. Not all of them, but most of them. (Netscape Navigator Days)
> When I was a young, green, university student, I was forced to use test(1) as the only true way to do testing in shell scripting. […] Yeah, I was also forced to not use semicolons as they were evil (according to my professor, any comment unneeded!).
The author’s professor clearly went overboard, but doesn’t this entire anecdote demonstrate the value of teaching it this way? Having green students call the `test` binary provides more insight into how UNIX operates, and gets them using a UNIX mindset. They can discover the syntactic shortcuts later.
I personally use ((...)) for arithmetic tests and [[...]] for all other tests as I just target new versions of BASH and don't care much about POSIX compatibility.
[[ ... ]] supports regex comparisons and lets you combine multiple conditions in a single bracket group using && and || instead of remembering to use -a / -o.
I usually default to [ ... ] unless I need features that double brackets provide.
Use ((...)) for arithmetic tests and [[...]] for other tests. [...] is for POSIX compatibility and not as useful as [[...]] though I don't remember the specifics.
Reminds me of my rather memorable introduction to special characters invoking functions, seeing this dastardly little quip in the email signature of someone in a mailing list (circa '95 or so).
My curiosity piqued, I pasted it into the shell on my terminal in a pure example of FAFO. The poor little Sparc 5 I was using ground to a halt over the course of about ten seconds. The reboot was as hard as the lesson. xDIn college I took a database class, it was pretty basic overall as I had been playing with MySQL for a few years at that point. On the final exam I got a 90/100. The test was 10 questions that just had you write SQL to answer the question. I got all the queries 100% correct... except... I didn't put a ";" after each query. On a written test. I'm still a little bitter about that.
The ultimately sad part was the professor in a Sun OS machine.
In a corner with no where to go, giving demerits because his bash was older than he realized.
Reminds me of my college professor that claimed you don’t have to close HTML tags (some you absolutely do) and I proved that you do. Not all of them, but most of them. (Netscape Navigator Days)
It doesn’t have anything to do with bash (though modern bash may use a built in for `[`). He don’t have the `[` program (usually linked to `test`).
So if you really want to troll someone, you can put them in quotes.
> When I was a young, green, university student, I was forced to use test(1) as the only true way to do testing in shell scripting. […] Yeah, I was also forced to not use semicolons as they were evil (according to my professor, any comment unneeded!).
The author’s professor clearly went overboard, but doesn’t this entire anecdote demonstrate the value of teaching it this way? Having green students call the `test` binary provides more insight into how UNIX operates, and gets them using a UNIX mindset. They can discover the syntactic shortcuts later.
Hmm. What if we replaced the whole of bash with the contents of /bin?
…you always need some sort of shell to call the binaries, don’t you? Or is that my own lack of UNIX knowledge talking?
I do think it makes sense to have beginners use `sh` instead of `bash`.
Nowadays [ is a builtin. The subprocess for a simple branch would be excessive overhead.
It is indeed a builtin, but `/bin/[` still exists for compatibility reasons!
The same is true for the `test` command:Here's Greg's Wiki about the difference between [, [[ and test
https://mywiki.wooledge.org/BashFAQ/031
Now do [ ... ] and [[ ... ]]
I'm still not sure when to use one or the other. I use double brackets by default until something doesn't work.
[[...]] is non-portable and has an extremely quirky corner case with variable expansion in arithmetic contexts, what's not to love?
It also does wildcards though, with POSIX you'll need a case statement for that.
I'm intrigued - any info on that?
I personally use ((...)) for arithmetic tests and [[...]] for all other tests as I just target new versions of BASH and don't care much about POSIX compatibility.
[[ ... ]] supports regex comparisons and lets you combine multiple conditions in a single bracket group using && and || instead of remembering to use -a / -o.
I usually default to [ ... ] unless I need features that double brackets provide.
Double brackets are less portable. For example musl linux does not come with bash by default, and your script fails.
When unsure, use shellcheck.
You mean shellcheck will detect when single brackets won't be enough? I've also just defaulted to double because I never really looked into it
[[ is built in, so "test[" as an /usr/bin artifact never exists? (What to call that proposed program, test2, or test[ ?)
Use ((...)) for arithmetic tests and [[...]] for other tests. [...] is for POSIX compatibility and not as useful as [[...]] though I don't remember the specifics.
[[…]] is a bash (probably other shells, too) built in. […] could be a built in, or could be a symlink to /bin/test.