Re: 'test' builtin of bash returns wrong value for '! -a FILE' operation

[OZAKI Masanobu]

Hello.

On Mon, 2010-11-08 at 08:45:11 -0500,
Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Fri, Nov 05, 2010 at 04:24:23PM -0500, Jonathan Nieder wrote:
> > >>> Please try
> > >>>   % bash -c 'test ! -a . && echo true'
> > >>> and compare with the result of
> > >>>   % bash -c '/usr/bin/test ! -a . && echo true'
> 
> imadev:~$ bash -c 'test ! -a . && echo true'
> true
> imadev:~$ bash -c '/usr/bin/test ! -a . && echo true'
> imadev:~$ 
> 
> This is an extremely convoluted example.  You're echoing true if the
> object does NOT exist...?  Actually, you're echoing true if the command
> fails to fail.  In the /usr/bin/test -a case, the command has the right to
> fail because there's no such unary operator (see below), regardless of
> whether . exists in the file system.

First of all, I made a mistake in the previous message: I wrote
"both should echo true" in previous email, but that is wrong.
Both should echo nothing, as you expect.  I am sorry for my confusing
message.

> (On my system, there is no -a unary operator in the test(1) man page, but
> the command apparently supports one, undocumented.  Isn't this fun?)

Neither on my system.  I found descriptions of the -a unary operator
in the output of "help test" output and ksh(1) man page.
According to Solaris 7's test(1) page
(http://docs.sun.com/app/docs/doc/805-3172/6j31br5p3?l=en&a=view),
which summarizes variations of test command, I guess this is ksh origin
and influenced (or polluted?:) /bin/test and bash.  I found the
inconsistency between bash-builtin and GNU shell util's test commands when
porting a ksh script to bash in order to avoid a ksh's bug that randomly
occurred on Scientific Linux.

Regards,
Masanobu