| 1 |
On Tue, 25 Jul 2006 15:41:56 +0200, Alan McKinnon wrote: |
| 2 |
|
| 3 |
> The answer is simple: |
| 4 |
|
| 5 |
Maye, but this isn't it. |
| 6 |
|
| 7 |
> 'test' is a bash builtin. When a bash script executes 'test', it is |
| 8 |
> not /usr/bin/test that runs, but a function internal to bash. |
| 9 |
|
| 10 |
test and [ are both Bash builtins, but there are also [ and test commands |
| 11 |
in /usr/bin. This has nothing to do with the builtins. |
| 12 |
|
| 13 |
|
| 14 |
> /usr/bin/test/ is provided for environments that want to run bash |
| 15 |
> scripts that use test but bash is not the shell in use. |
| 16 |
|
| 17 |
Those scripts can also use /usr/bin/[ |
| 18 |
|
| 19 |
> test and [ are not links to each other as they have different syntax |
| 20 |
> (the closing ]), so they cannot be the same command. If they were |
| 21 |
> linked, one of them would fail on execution with invalid syntax errors |
| 22 |
|
| 23 |
That's wrong, as explained in my previous response that you quoted. A |
| 24 |
command receives the name it was invoked with as one of its arguments. So |
| 25 |
it is possible for a command to operate differently according to the name |
| 26 |
used to run it, such as the gzip/gunzip/zcat example I gave earlier, or |
| 27 |
the hundreds of commends in netpbm that are mainly symlinks to a few core |
| 28 |
commands. |
| 29 |
|
| 30 |
It's possible to do this with scripts too, I have a number of scripts |
| 31 |
that act differently according to the name used to run them. |
| 32 |
|
| 33 |
|
| 34 |
-- |
| 35 |
Neil Bothwick |
| 36 |
|
| 37 |
Plagarism prohibited. Derive carefully. |
Archives