m4: fix test(1) operator

[0-wiz-0]

'=' is the operator defined by POSIX, only bash supports '=='

[0-wiz-0]

The failing checks are connection problems with github.

[vszakats]

Maybe say 'Apple SecTrust' in the title or commit message to narrow the scope of the issue?

[0-wiz-0]

The problem is this becomes part of the main configure script, so all systems are affected.

[vszakats]

The problem is this becomes part of the main configure script, so all systems are affected.

Would these test commands be only executed if the SecTrust option is enabled?

[0-wiz-0]

I think yes.
I've added 'sectrust' to the commit message.

[icing]

@0-wiz-0 thanks. Silly me for sticking to bash on my macos dev machine. But why was this not noticed in CI, I wonder?

With what local setup do you see the problem?

[0-wiz-0]

We have an extra check for this kind of incorrect test(1) in pkgsrc.

[vszakats]

@0-wiz-0 thanks. Silly me for sticking to bash on my macos dev machine. But why was this not noticed in CI, I wonder?

With what local setup do you see the problem?

macOS uses zsh by default (and previously used bash IIRC), and should not be affected.

I was looking for a shellcheck solution for m4 files for a while, but didn't find any so far. It'd be super to use one if such tool existed.

[bagder]

I was looking for a shellcheck solution for m4 files for a while, but didn't find any so far. It'd be super to use one if such tool existed.

Does it blow up if we run it on the generated configure script?

[vszakats]

I was looking for a shellcheck solution for m4 files for a while, but didn't find any so far. It'd be super to use one if such tool existed.

Does it blow up if we run it on the generated configure script?

Something to try ...it took 177 seconds (on a fast machine) and
the result is 5100 warnings, 1 MB of log output.

Part of the problem is that lots of code is coming from autotools
itself. Another is that it's written for very old standards.

Maybe possible to tweak options to tame results a bit, but one run
taking so much time, it'd be quite a task.

I have an open PR aiming to tidy up mainly ifs, I plan to continue
with the TODOs/idea pending there (also possibly-maybe keeping
the dreaded xs for input values): #18189

[bagder]

I tried checkbashisms.pl from Debian's devscripts 2.25.23 package on the generated configure from 8.17.0 to see what it says. It didn't work:

error: /home/dast/src/curl/configure:  Unterminated heredoc found, EOF reached. Wanted: <_EOT>, opened in line 194

[vszakats]

_EOT

A heredoc within backticks:

xc_tst_str=`cat <<_EOT 2>/dev/null \
  | wc -l 2>/dev/null | tr -d "$xc_space$xc_tab" 2>/dev/null
unknown
unknown
unknown
_EOT`

[bagder]

Thanks!

[dfandrich]

It would be easy to run the configure script using an alternate shell in CI (e.g. something like "busybox ash ./configure CONFIG_SHELL=ash --foo"). But, things like = vs == would probably just output a message and silently skip whatever option was being tested so it would take some post-configure checking that the results were as expected.