On Thu, Oct 13, 2011 at 9:50 AM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > On Thu, 13 Oct 2011 15:38:08 +0200 > Jesús J. Guerrero Botella <jesus.guerrero.bote...@gmail.com> wrote: > >> Yes, it's a different binary, and it's perfectly usual to find it in a >> Linux system. >> >> But note that, at least in bash, you rarely will be using /usr/bin/[ >> unless you reference it using the full path (either in a relative or >> absolute way). This is because bash has a builtin that takes over that >> binary file. You can check that (or any other command) by using the >> "type" instruction (again, this is for bash). >> >> # LC_ALL=C type [ >> [ is a shell builtin >> >> The same goes for 'test'. >> >> Those binaries are probably there just in case that some init or >> system script written for a standard bourne shell (like the busybox >> one) needs it. But don't take my word for it. I am not sure right now. > > You might not be sure, but that doesn't stop you still being correct :-) > > The binaries are usually POSIX-compliant, whereas the builtins may > include extra bashisms (which tend to break apps expecting just > the basic POSIX behaviour)
I haven't encountered POSIX-dependent apps breaking on bash, but I have encountered the reverse. My most annoying experience was when I tried building cinelerra on Debian a few years back. Cinelerra's script started with #!/bin/sh, but depended on bashisms--and I was running dash. -- :wq
