Fish 3.2.2 repairs macOS failures in interactive shell work

A shell can fail while displaying a command that has never been executed. Fish's syntax highlighter examines arguments as the user types, including whether they might be paths. A macOS-specific failure in that work could turn a sufficiently long argument into sustained CPU consumption. Fish 3.2.2, released on April 7, corrects the problem.

The release notes describe arguments longer than 1024 characters as the trigger. The original report in issue 7837 is more revealing about when it happened. Pasting or typing the long argument after a command name was sufficient. There was no need to execute the command and wait for the invoked program to misbehave.

I like fish's live feedback because it makes command construction more legible. This bug shows why that convenience also makes background shell work part of the interactive reliability contract. A feature that runs while text is still being edited must handle unusual input without consuming resources indefinitely.

A path check crossed a platform boundary

The issue discussion traces the problem to the highlighter checking potential paths. It called dirname to find the parent of an argument. The developer's explanation distinguishes Linux behavior from macOS behavior. On macOS, the system function can fail when its internal storage cannot accommodate a path longer than PATH_MAX, returning a null pointer.

Fish then attempted to construct a C++ string from that null result. The discussion identifies a second problem in the background thread's signal handling. The resulting segmentation signal did not terminate the process as the developer had expected. That thread repeatedly encountered the same failure, producing the sustained CPU use.

This explains why the symptom was not simply a slow operation on a large string. The failure repeated because of the interaction between the platform function and signal handling. The amount of typed text selected the bad path, but the loop came from what happened after the library function failed.

The developer identifies several corrective requirements in the discussion. Fault signals must not be blocked in background threads, the system-provided dirname dependency should be replaced, and path detection can be skipped for arguments longer than the platform path limit. These address different parts of the failure sequence. Making a fault terminate the process would expose the bug, while avoiding the invalid operation prevents it.

The discussion also records reproductions without the original reporter's configuration and without the terminal multiplexer initially suspected. That evidence matters because the first report involved a particular terminal setup. A reproduction with those customizations removed narrows the explanation to shell behavior instead of attributing the failure to every component present in the first environment.

Exit handling also depends on terminal ownership

A separate macOS fix concerns leaving the shell while another process is in the foreground. Issue 7901 gives a short reproduction: start fish, start zsh inside it, then close the terminal window. The inner shell exits, but fish can hang.

The report explains that fish tried to return the terminal to its original owner while fish itself was not controlling the terminal. A previous job-control change had altered the relevant signal behavior. This was therefore an exit-path problem involving terminal ownership, not a claim that ordinary execution of zsh was incompatible with fish.

The release notes scope the observed hang to macOS. Preserving that scope is useful. The linked discussion explicitly says the reporter could not reproduce it on Linux or FreeBSD. A description that treated it as a universal shell exit failure would discard information the maintainers used to characterize the bug.

Input recovery after a full-screen program

The release also makes fish more robust after programs such as lazygit. Issue 7853 reports broken multi-character Vi bindings after returning from that program. Another reproduction describes arrow keys eventually printing pieces of their escape sequences.

The investigation points to repeated SIGIO interruptions while fish waits for input. Those interruptions made multi-character key sequences unreliable. The developer notes uncertainty about how the asynchronous notification behavior remained associated with fish, so the report should not be converted into a more definitive claim about descriptor inheritance than its evidence supports.

For the user, the relevant boundary is returning to the command-line editor. A full-screen program can leave the shell needing to interpret subsequent terminal input correctly. The patch release addresses that recovery, alongside a separate regression where background jobs interfered with syntax highlighting.

I regard these fixes as material to fish's appeal as an interactive shell. Responsive editing depends on path inspection, signal handling, and terminal control behaving correctly around other programs. Version 3.2.2 repairs failures in those supporting operations, including the case where displaying a long argument consumed CPU before any command had run.