Hello. On Mon, 2010-11-08 at 08:45:11 -0500, Greg Wooledge <wool...@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
