Re: behavior of test true -a \( ! -a \)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Thu, Mar 21, 2024 at 10:39 AM Bart Schaefer
<schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> I'm guessing the change is from commit 2afa556d8 (workers/31696).

That commit includes this comment:

+       /*
+        * In "test" compatibility mode, "! -a ..." and "! -o ..."
+        * are treated as "[string] [and] ..." and "[string] [or] ...".
+        */

The way this is tested was changed first at commit cb596a55
(workers/35306) and again at commit daa208e9 (workers/49269) to end up
with this:

        if (!(n_testargs > 2 && (check_cond(*testargs, "a") ||
                                 check_cond(*testargs, "o"))))

So this means that in the original example:

% test true -a \( ! -a \) ; echo $?
test: argument expected

The closing \) is being treated as the string argument of [ ! -a \) ]
rather than as a match for the opening \(.

Which you can see by:

% test \( ! -a \) \)
% echo $?
0
% test \( ! -a \) \) \)
test: too many arguments

I'd therefore argue that it's actually

% test \( ! -a \)

that is wrong: It should be complaining of a missing close paren,
rather than magically reverting to treating "!" as "not" (and also
"-a" as a plain string).  It's entirely dependent on the count of
arguments rather than on treating parens as tokens.