#1152274 checkbashisms: 'command' false positive on "command -v -- name" (-- is end-of-options, not an option)

Package:
devscripts
Source:
devscripts
Description:
scripts to make the life of a Debian Package maintainer easier
Submitter:
Tomáš Chvátal
Date:
2026-10-27 11:33:02 UTC
Severity:
normal
#1152274#5
Date:
2026-10-27 11:27:19 UTC
From:
To:
    #!/bin/sh
    command -v -- "$prg"

Actual output (checkbashisms 2.26.9, exit 1):

    possible bashism in test.sh line 2 ('command' with option other
than -p, -v or -V):
    command -v -- "$prg"

Expected: no output. "--" is the standard end-of-options marker
(POSIX XCU 12.2, Guideline 10), not an option to command; the
operand after it is the utility name, which is exactly why the
idiom is used before a possibly dash-leading name. dash accepts
the line. The related option-parsing issue #835498 was fixed in
2.20.3, but a bare -- is still misread as an option in 2.26.9.

Found downstream (openSUSE/rpmlint corpus): ~30 instances, in the
hdf5 wrapper family and elsewhere.

Disclosure, encouraged by GR 2026-002: this report was drafted with
AI assistance; the reproducer was verified by me against
checkbashisms 2.26.9.
#1152274#10
Date:
2026-10-27 11:30:33 UTC
From:
To:
The attached patch (against devscripts master) fixes this bug:
the 'command' option check no longer treats a bare "--" as an
option token. Only the exact end-of-options marker is exempted;
bad options still fire, before or after it (e.g.
"command -p -a test", "command -a -- foo").

Two regression lines are added to test/bashisms/command.sh:
"command -v -- test" and "command -- test" now stay silent.
Verified: the full test/test_checkbashisms suite passes with the
patch; the added lines fail without it.

Disclosure, encouraged by Debian GR 2026-002: this patch was
prepared with AI assistance; it was verified by me against the
reproducers and the devscripts test suite.