fish 3.7.1 restores the existence check behind wildcard expansion

A wildcard result should describe a path that matched the filesystem. In fish 3.7.0, a trailing slash could break that expectation. A pattern could produce existing prefixes with a nonexistent suffix appended, making the expanded argument look more authoritative than the filesystem justified. fish 3.7.1 restores the existence check that distinguishes a constructed candidate from a real match.

The 3.7.1 release notes, dated 19 March, identify wildcard expansion and history deletion as regressions from 3.7.0. The tagged changelog also describes a crash while reporting failure to launch an ELF executable with a missing interpreter. These are small corrections with distinct mechanisms.

I value an interactive shell that makes ordinary commands easier to construct. That convenience depends on precise expansion behavior. A result inserted by the shell should retain the matching properties that distinguish expansion from manually concatenating strings.

A trailing slash changed the path check

Issue 10205 reports a concrete difference between two patterns under /etc. Without a final slash, searching through wildcard-selected directories for a conf.d component behaved as expected. Adding the final slash caused the reported expansion to append conf.d/ to entries where the directory did not exist.

The distinction can be observed using the report's read-only commands.

echo /etc/*/conf.d
echo /etc/*/conf.d/

The exact results depend on the machine's directories. The bug is not that the commands must always print identical text. It is that the trailing-slash form must not invent a matching path merely because an earlier component exists.

The corrective commit reverts removal of an access check in the trailing-slash expansion path. The old implementation added the accumulated directory path directly, with a comment assuming it was already known to exist. That assumption was invalid for the reported pattern.

The restored code calls the existence check before adding the candidate. If the path does not exist, it does not become an expansion result. The accompanying regression uses a pattern ending in */foo/ and expects an unmatched-wildcard diagnostic when the suffix is absent.

The source also separates ordinary expansion from completion. A partially typed token during completion is not held to exactly the same requirements as a finished wildcard used to construct a command's arguments. Keeping those contexts separate matters when deciding whether a candidate should be offered for editing or accepted as a filesystem match.

The practical consequence is at argument construction time. Programs receive the paths that expansion produces, so a nonexistent result may lead to an error or another program-specific interpretation. The patch repairs the shell's contribution before any such downstream behavior occurs. It does not require changing the programs invoked with those arguments.

The final numbered history result is valid

The history deletion patch in pull request 10190 corrects a boundary comparison in the interactive deletion function. The function checks whether a supplied index is positive and lies within the number of found entries. Its old comparison required the index to be strictly less than that count.

For a one-based result list, the last valid index equals the count. The old check consequently rejected the final numbered result. A list containing one match was an especially direct example, because its only entry was also its last entry.

The patch changes the comparison to less than or equal. It preserves the positive-integer check and the rejection of indices beyond the result count. This restores selection of the last result without making arbitrary out-of-range choices valid.

The release description's phrase about the last history entry should therefore be understood through the selection implementation. The correction concerns the final item in the results presented for deletion. It is not evidence that only the chronologically newest command could have been affected.

Launch failure should retain its original explanation

The ELF error-reporting patch in pull request 10199 handles an absent interpreter pointer before calling stat. The previous code could call that filesystem operation without a valid interpreter string, producing a secondary failure while explaining why execution failed.

The corrected expression short-circuits when no interpreter string exists. Later logic already checks for an interpreter before inspecting its accessibility. The patch brings the earlier filesystem check under the same basic requirement.

The changelog explicitly locates this crash in the process after fork. The interactive fish process that attempted to launch the program was not itself the crashing process. That qualification prevents a misleading account of the failure as an interactive shell session disappearing.

I expect a failed command launch to leave an explanation that identifies the executable problem. A crash in the diagnostic path can instead make the observed signal look like the primary failure. Keeping that reporting path valid helps distinguish an unavailable interpreter from a program that actually started and then crashed.