| 1 |
On Thu, 13 Oct 2011 15:38:08 +0200 |
| 2 |
Jesús J. Guerrero Botella <jesus.guerrero.botella@×××××.com> wrote: |
| 3 |
|
| 4 |
> Yes, it's a different binary, and it's perfectly usual to find it in a |
| 5 |
> Linux system. |
| 6 |
> |
| 7 |
> But note that, at least in bash, you rarely will be using /usr/bin/[ |
| 8 |
> unless you reference it using the full path (either in a relative or |
| 9 |
> absolute way). This is because bash has a builtin that takes over that |
| 10 |
> binary file. You can check that (or any other command) by using the |
| 11 |
> "type" instruction (again, this is for bash). |
| 12 |
> |
| 13 |
> # LC_ALL=C type [ |
| 14 |
> [ is a shell builtin |
| 15 |
> |
| 16 |
> The same goes for 'test'. |
| 17 |
> |
| 18 |
> Those binaries are probably there just in case that some init or |
| 19 |
> system script written for a standard bourne shell (like the busybox |
| 20 |
> one) needs it. But don't take my word for it. I am not sure right now. |
| 21 |
|
| 22 |
You might not be sure, but that doesn't stop you still being correct :-) |
| 23 |
|
| 24 |
The binaries are usually POSIX-compliant, whereas the builtins may |
| 25 |
include extra bashisms (which tend to break apps expecting just |
| 26 |
the basic POSIX behaviour) |
| 27 |
|
| 28 |
-- |
| 29 |
Alan McKinnnon |
| 30 |
alan.mckinnon@×××××.com |
Archives