Re: [PATCH] tools: remove unnecessary x suffix in test strings

[Kevin Locke <kevin@kevinlocke.name>]

On Sun, 2025-10-19 at 11:17 +0100, David Laight wrote:
> On Fri, 17 Oct 2025 16:28:12 -0600 Kevin Locke <kevin@kevinlocke.name> wrote:
>> On Fri, 2025-10-17 at 15:12 +0100, David Laight wrote:
>>> On Thu, 16 Oct 2025 17:47:09 -0600 Kevin Locke <kevin@kevinlocke.name> wrote:  
>>>> Remove the "x" suffixes which unnecessarily complicate the code.  
>>> 
>>> The problems arise when $1 is (say) "-x", a simple LR parser will treat
>>> [ -x = -x ] as a check for the file "=" being executable and then give
>>> a syntax error for the second -x.
>>> I can't imagine why shellcheck should warn about a leading x (or any other
>>> character) provided field splitting is disabled (eg by "").
>>> The leading x has definitely been needed in the past.  
>> 
>> Yep, it definitely has been.  The rationale on the wiki is that it's
>> not necessary for modern shells (and presumably that it unnecessarily
>> complicates the code): https://www.shellcheck.net/wiki/SC2268
>> However, it notes Zsh had issues as recently as 2015, which is not as
>> old as I would have expected.
> 
> It doesn't really make much difference to the shell.
> I really doubt you'll notice any difference in the time it takes to run.

I agree.  However, I'm more concerned about readability and
understandability for developers less familiar with the quirks of old
shells.

>>> POSIX does require the three argument 'test' look for the middle argument
>>> being an operator - but there might be historic shells that don't so that.
>>> OTOH you are probably looking for code from the early 1980s!
>>> But the POSIX spec (last time I read it) does point out the problems
>>> with arbitrary strings being treated as operators causing complex expressions
>>> be mis-parsed - which a leading x fixes.  
>> 
>> Good point.  I just reread it and can confirm that the current version
>> still notes issues mitigated by the X prefix with "historical shells"
>> and with greater than 4 argument cases:
>> https://pubs.opengroup.org/onlinepubs/9799919799/utilities/test.html
> 
> The fact that the 'greater than 4 argument case' can still require
> a prefix character might be considered enough to make adding one all the
> time 'good practise' even though it (probably) isn't actually needed.

That seems reasonable to me, although I'd prefer omitting x and
prohibiting >3 argument cases, which appears to be the route
shellcheck takes with SC2268 + SC2166.

> While I wouldn't error not having a prefix, generating an error when
> there is one seems wrong.
> What does shellcheck do with [ "$a" = "$b" -o "$c" = "$d" ] ?

It only produces SC2166 (discouraging -o).  However, for 
[ "x$a" = "x$b" -o "x$c" = "x$d" ] it also produces SC2268.

> Or even [ "$a" "$b" "$c" "$d" "$e" "$f "$g" ] ??

This, and [ "$a" "$b" "$c" ] and [ "$a" "$b" ] produce parser error
SC1073.  Unfortunately, this appears to be a long-standing shellcheck
issue:  https://github.com/koalaman/shellcheck/issues/1645

>> I find && and || more readable, but I'm open to changing it if you
>> feel strongly.
> 
> They get parsed entirely differently and are likely to be measurably slower.
> Just FYI I tend not to use 'if' statements at all, just (eg):
> 	[ a = b ] && echo a == b
> 
>> Do I understand correctly that you are in favor of using the x prefix?
>> I have a slight preference for leaving it off, but I'm open to adding
>> it if you (or others) feel strongly.
> 
> I wouldn't take them out and consider shellcheck wrong, but the suffix
> were just stupid.

Are you opposed to the patch I posted removing the suffixes?  I had
tagged you as Suggested-by due to misreading your first post.  If the
change is not something you'd suggest, I can repost without it.

Thanks,
Kevin