gdiffmk and FreeBSD expr (was: groff 1.23.0.rc3 on FreeBSD)

[G. Branden Robinson]

[self-follow-up]

At 2023-03-06T09:56:37-0600, G. Branden Robinson wrote:
> At 2023-03-06T01:56:56+0100, Bruno Haible wrote:
> > On FreeBSD 13.1, the build succeeds, but there is 1 test failure:
> > 
> > FAIL: contrib/gdiffmk/tests/runtests.sh
> > 
> > Find attached the log. Apparently non-numeric arguments get passed
> > to the 'expr' program.

As noted earlier, gdiffmk does this on purpose to implement its option
parser.

> FreeBSD expr is rejecting arguments that are structured like options,
> but which it doesn't recognize, instead of interpreting them as
> literals.  Presumably this is why they keep flogging their '-e' flag
> in their diagnostics.  I'll look at POSIX for guidance.

As far as I can tell there's nothing wrong gdiffmk using expr this way.

POSIX Issue 4 does not admit any options to the "expr" command, and
neither do Issues 6 or 7.  (I didn't bother to check Issue 5.)

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html

Rather than refactor gdiffmk this close to a release, I think I would
prefer to don my Ralph Corderoy mask and accuse FreeBSD of deviationism.

...and to document this as a known issue in the "PROBLEMS" file.

I do see a lengthy apologium for this behavior in FreeBSD's man page
("Compatibility with previous implementations").

https://man.freebsd.org/cgi/man.cgi?query=expr&sektion=1

So maybe the right thing to do is have gdiffmk prepend "--" to the expr
argument list when using it to process its own arguments.

FreeBSD's man page is somewhat strident that expr is obsolete and should
be replaced with shell built-in commands.  (At least when it comes to
arithmetic, but what gdiffmk wants here is not arithmetic.)  I'd be more
receptive to that advice if I had not seen some evidence that, and read
more regarding, the shell's behavior being just about the _least_
reliable of anything to be found on a purportedly POSIX system.

> (Also, exiting with a status > 125 from a shell script is a bad idea;
> POSIX also talks about this.  But it's a separate issue.)

I reckon I'll fry these fish together, some time after release.

Regards,
Branden

signature.asc
Description: PGP signature