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

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

> On 21/03/2024 11:04 GMT Vincent Lefevre <vincent@vinc17.net> wrote:
> On 2024-03-21 10:28:16 +0000, Peter Stephenson wrote:
> > I haven't had time to go through this completely but I think somewhere
> > near the root of the issue is this chunk in par_cond_2(), encountered at
> > the opint we get to the "!":
> > 
> >     if (tok == BANG) {
> > 	/*
> > 	 * In "test" compatibility mode, "! -a ..." and "! -o ..."
> > 	 * are treated as "[string] [and] ..." and "[string] [or] ...".
> > 	 */
> > 	if (!(n_testargs > 2 && (check_cond(*testargs, "a") ||
> > 				 check_cond(*testargs, "o"))))
> > 	{
> > 	    condlex();
> > 	    ecadd(WCB_COND(COND_NOT, 0));
> > 	    return par_cond_2();
> > 	}
> >     }
> > 
> > in which case it needs yet more logic to decide why we shouldn't treat !
> > -a as a string followed by a logical "and" in this case.  To be clear,
> > obviously *I* can see why you want that, the question is teaching the
> > code without confusing it further.
> 
> Perhaps follow the coreutils logic. What matters is that if there is
> a "(" argument, it tries to look at a matching ")" argument among the
> following 3 arguments. So, for instance, if it can see
> 
>   ( arg2 arg3 )
> 
> (possibly with other arguments after the closing parenthesis[*]), it
> will apply the POSIX test on 4 arguments.
> 
> [*] which can make sense if the 5th argument is -a or -o.

I suppose as long as we only look for ")" when we know there's one to
match we can probably get away with it without being too clever.  If
there's a ")" that logically needs to be treated as a string following a
"(" we're stuck but I think that's fair game.

Something simple like: if we find a (, look for a matching ), so blindly
count intervening ('s and )'s regardless of where they occur, and then
NULL out the matching ) temporarily until we've parsed the expression
inside.  If we don't find a matching one treat the ( as as a string.

pws