fish 2.6 beta separates background jobs from shell ownership
fish 2.6b1 adds disown and lets command substitutions access the terminal. The changes give interactive programs more explicit control over job lifetime and user interaction.
Putting a process in the background does not remove it from the shell's job management. The process can keep running while fish remembers it, reports it and sends it a hang-up signal when the shell terminates. fish 2.6b1 adds disown to make removal from that management an explicit operation.
The May 14 beta notes pair that addition with terminal access for command substitutions. Both changes concern the relationship between an interactive shell and the programs it starts. One changes whether fish continues to manage a job, while the other lets a program interact with the terminal while its output is being captured.
I value fish's interactive behavior because useful operations should not require reconstructing shell internals in configuration. These additions make two common intentions expressible through the shell's own interfaces.
Background execution still belongs to the job list
The beta's disown reference says jobs in fish's list receive a hang-up signal when fish terminates. That usually causes them to terminate. A background job therefore still has a relationship to the shell's lifetime.
disown removes a job from the list while leaving the job itself in existence. fish no longer keeps track of it. This is different from merely allowing a running job to execute without occupying the foreground.
The command accepts process IDs. With no argument, it removes the most recently used job, following the selection convention of bg and fg. That convenience also makes the current job context relevant when the caller omits an identifier.
The reference provides this operation for removing all jobs from fish's list:
disown (jobs -p)
The substitution supplies the process IDs reported by jobs -p. The result is removal from fish's management, not a request to terminate the processes. This operation should therefore be read as an ownership change in the shell's job table.
Removing a job also removes shell controls
A disowned job can no longer be resumed through fish's bg builtin. The reference specifically notes this consequence. Once the shell no longer tracks the job, its job-control commands no longer have the same object to operate on.
For a stopped job, disown sends a continuation signal and prints a warning. This prevents removal from the list from leaving the documented stopped job waiting for a later bg command that can no longer address it.
The command returns zero when all requested jobs are disowned successfully and one when problems occur. Invalid jobs produce warnings. A script that needs to know whether the ownership change succeeded can therefore examine the command's status.
Disowning also does not describe every resource a process might use after the shell exits. The command's documented guarantee concerns fish's tracking and hang-up behavior. It does not promise to replace a terminal connection, redirect output or provide service supervision.
That limit helps identify appropriate use. Removing a job from an interactive shell is a smaller operation than arranging a service's complete runtime environment. The former is what this builtin supplies.
Captured output can coexist with terminal interaction
The second change lets command substitutions access the terminal. The release notes identify tools such as fzf as beneficiaries. A program can present an interactive selection while the shell captures the value it emits for use in the surrounding command.
Capturing a program's output does not inherently mean the program has no need to ask the user a question. An interactive selector has both an interface and a result. Treating terminal interaction as incompatible with substitution prevents that combination.
This release makes the combination possible in fish's substitution context. It does not require every substitution to become interactive, or change the intent of ordinary commands that simply emit a value. The additional capability matters when the child program actually needs the terminal.
I prefer that separation between the interface and its result. An interactive tool can manage its selection UI while the shell receives the chosen value through the normal expression mechanism.
The beta also changes process-launching internals
The notes describe performance improvements in process launching, including reduced signal blocking. They provide FISH_NO_SIGNAL_BLOCK=0 as a fallback setting for the previous behavior if problems occur. That is a beta-specific implementation qualification, not a measured speedup that applies equally to every workload.
Prompt functions that set many colors also receive performance work. These changes affect frequent interactive operations, but the release notes give no universal latency number. Their practical scope can be stated without inventing a benchmark.
The same beta adds silent input to read and improves bracketed paste support on compatible terminals. Those changes also concern interaction with the terminal, although they solve different problems from job ownership.
The new job-control interface remains precise. A job can run in the background while fish tracks it, and disown can remove that tracking explicitly. Command substitutions can now involve terminal interaction while returning a value. Together they give fish users more control over how child programs participate in the current session.