Re: grammar triviality with '&&'

[Kurtis Rader <krader@xxxxxxxxxxxxx>]

On Mon, Mar 2, 2015 at 8:15 PM, ZyX <kp-pav@xxxxxxxxx> wrote:
>
> I do not think this is a mistake. And I found at least two differences:
>
> 1. `command test --help` returns zero, `command \[ --help` displays help.
> 2. `[` requires `]` (unless it received `--help` or `--version`), no
> matter what name it is called with, `test` requires not.
>
> Note that coreutils ebuild does *not* contain any references to `test` or
> `[`, patches as well do not (except when Makefile is patched not to
> regenerate man pages). This means that this difference is created by GNU
> developers, *not* by distro maintainers.
>

Ugh! I can confirm your observations using my Ubuntu 14.04 server. Yet on
Mac OS X Yosemite the two names are linked to the same binary. Mac OS X
exhibits the traditional behavior. I have no idea why GNU based distros
have the two names linked to slightly differently behaving binaries.
Presumably the GNU team had a good reason for this departure from the
traditional behavior. Furthermore, the GNU team could have used a single
binary for both names since a program can easily use the name it was
invoked by to alter its behavior. But that difference doesn't affect my
point that traditionally /bin/test and /bin/[ referred to the same program
and /bin/sh didn't know how to do anything other than invoke an external
command with a sequence of "words" and evaluate its exit status. So "if [
some condition ]; then" was really just "if /bin/[ some condition \] ;
then".

Note that quoting is critical. Which is the main reason the Korn-shell
(ksh) introduced the "[[ ... ]]" syntax. Invoking /bin/[ (or /usr/bin/[)
requires a trailing "]". Invoking /bin/test (or /usr/bin/test) requires
that there be no trailing "]". How the arguments are passed to the two
commands is also important. The "/bin/[" form requires that the shell has
already tokenized the condition into words.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank