GlobFilter: bare wildcard patterns ('*', '**', '?') for -f/-e do not match as expected

[djkees]

Summary

Filtering with -f/--filter or -e/--exclude using a pattern made up only of wildcard characters (*, **, ***, or ?) does not behave as documented. A bare * (which should mean "match everything") matches nothing, and a bare ? (which should only match single-character test names) matches everything - the opposite of the intended semantics in each case. Patterns that combine wildcards with literal text work correctly.

Reproduction

• Windows 11, gfortran 16.1.0 (conda-forge), CMake 4.4.2, Ninja
• Built pFUnit's own test suite (tests/funit-core) and ran the driver-based new_tests.x executable directly:

./new_tests.x -f 'AssertString*'   # -> 33 tests   (correct: prefix-wildcard works)
./new_tests.x -f '*'               # -> 0 tests    (WRONG: should be all 213)
./new_tests.x -f '**'              # -> 0 tests    (WRONG: should be all 213)
./new_tests.x -e '*'               # -> 213 tests  (WRONG: should exclude everything, leaving 0)
./new_tests.x -f '?'               # -> 213 tests  (WRONG: should match only 1-character test names, i.e. 0)

Reproduced identically on Git Bash and PowerShell, independent of quoting style, so this isn't a shell/quoting issue.

Note: MinGW/MSVCRT's command-line wildcard argv expansion (a real Windows CRT behavior where */? arguments can be silently expanded against files in the current working directory before main() ever sees them) is a real confounder here - one of my earlier test runs produced a false result because the working directory happened to contain files matching the pattern. I controlled for this by re-testing from directories with no glob-matching files present, and the -f '*' / -f '**' / -e '*' / -f '?' failures reproduce regardless.

What's NOT the cause

• GlobPattern.F90's matching algorithm itself is correct: hand-tracing match_() for pattern "*" against an arbitrary non-empty string recurses correctly to .true.. It's also exercised by pFUnit's own Test_GlobPattern.F90, which passes - but that suite only ever checks a bare "*" pattern against the literal one-character string "*" (Test_GlobPattern.F90:35), never against a realistic longer test name, so this edge case has no coverage.
• Patterns combining wildcards with literal content work correctly in every case tested, including leading-and-trailing wildcards (*IgnAllWhite* correctly narrowed 33->26 via -e) and multi-pattern OR logic (-f 'AssertString*' 'AssertEqual_Complex*' correctly gave 33+11=44).

I wasn't able to pin down the exact faulty line - it's somewhere between fArgParse's variadic (n_arguments='*'/'+') argument collection in extern/fArgParse/src/ArgParser.F90:476-499 and FUnit.F90's apply_include_filters/apply_exclude_filters (src/funit/FUnit.F90:177-272), since neither GlobPattern.F90's algorithm nor the CLI's basic plumbing (confirmed working via the literal+wildcard cases above) appears broken on its own.

Why this wasn't caught by existing tests/CI

• The only test harness for -f/-e (tests/funit-core/test_command_line_filtering.sh) never exercises a pattern made purely of wildcard characters - every case pairs a wildcard with a literal prefix (e.g. test_alpha_*).
• On Windows CI specifically, that script currently can't even run - see Tests command_line_filtering and shuffle_integration fail on Windows (BAD_COMMAND) #568, where CTest passes it as a COMMAND pointing at a .sh file, which fails immediately with BAD_COMMAND under Windows' CreateProcess().

Suggested next step

Add explicit test cases for bare *, **, and ? patterns (matched against non-trivial test names, not just single-character strings) to Test_GlobPattern.F90 and to test_command_line_filtering.sh, then step through apply_include_filters/apply_exclude_filters with tracing added for a bare-* invocation to isolate exactly where the pattern value is lost or mishandled.

---

Drafted with Claude's assistance.

• Reproduced independently across two shells (Git Bash, PowerShell) and multiple working directories to rule out shell quoting and Windows CRT argv wildcard-expansion as the cause.
• Verified the GlobPattern matching algorithm is correct by hand-tracing its recursion for the failing case, and confirmed via Test_GlobPattern.F90's existing (passing) unit tests that it lacks coverage for this specific input shape.
• Confirmed the connection to Tests command_line_filtering and shuffle_integration fail on Windows (BAD_COMMAND) #568 by reading its description directly, and independently ran test_command_line_filtering.sh by hand to verify it also lacks coverage for bare-wildcard patterns.

🤖 Generated with Claude Code