Fish Scripting: Process Management Complete Guide

Introduction to Process Management in Fish Shell

Process management is a fundamental aspect of shell scripting that allows you to control how programs execute, monitor their state, and coordinate multiple running tasks. The Fish shell (friendly interactive shell) provides a clean, modern approach to process management that differs significantly from traditional POSIX shells like Bash or Zsh. Understanding these differences is essential for writing robust, efficient Fish scripts.

At its core, process management in Fish covers launching processes in the foreground or background, tracking their lifecycle, sending signals, handling exit statuses, and orchestrating complex pipelines. Fish simplifies many of these operations while introducing its own idioms that feel more intuitive once you grasp the underlying model.

Why Process Management Matters

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

Effective process management is critical for several reasons:

Resource utilization – Running multiple processes concurrently maximizes CPU and I/O throughput, especially on multi-core systems
Responsiveness – Backgrounding long-running tasks keeps your shell interactive and available for other commands
Reliability – Proper signal handling and exit status monitoring prevent orphaned processes and resource leaks
Automation – Scripts often need to spawn, monitor, and terminate child processes without manual intervention
Parallelism – Data processing pipelines benefit from running independent stages simultaneously rather than sequentially

Foreground and Background Execution

Running Commands in the Foreground

By default, every command in Fish runs in the foreground, blocking the shell until it completes. This is the simplest mode and works identically to other shells:

# Simple foreground execution
echo "Starting long computation..."
sleep 10
echo "Done!"

The shell waits for sleep 10 to finish before printing "Done!". During this time, you cannot interact with the shell.

Launching Background Processes

To run a command in the background, append the & operator to the end of the command line. Fish immediately prints the job ID and process ID, then returns control to the shell:

# Launch a background task
sleep 30 &

# Fish prints something like:
# Job 1: 'sleep 30' has PID 12345, running in background

You can launch multiple background processes simultaneously:

# Start several background tasks
sleep 10 &
sleep 20 &
sleep 30 &

# All three run concurrently
echo "All tasks launched!"

Unlike Bash, Fish does not require disown or nohup for background jobs to persist after the shell exits — Fish automatically disowns background jobs when the shell terminates gracefully.

Capturing the Last Background PID

Fish provides the special variable $last_pid which holds the process ID of the most recently launched background process:

# Launch a background process and capture its PID
long_running_task &
set task_pid $last_pid
echo "Task PID is $task_pid"

# Later, check if it's still running
if kill -0 $task_pid 2>/dev/null
    echo "Task is still running"
else
    echo "Task has finished"
end

The $last_pid variable is unique to Fish and replaces the $! syntax found in POSIX shells.

Job Control Commands

Listing Active Jobs

The jobs builtin displays all background jobs associated with the current Fish session:

# Start several background jobs
sleep 100 &
sleep 200 &
sleep 300 &

# List all jobs
jobs

# Sample output:
# Job 1: 'sleep 100' running
# Job 2: 'sleep 200' running
# Job 3: 'sleep 300' running

Each job has a unique integer ID. You can reference jobs by this ID prefixed with %, or by their process ID.

Bringing Jobs to the Foreground

Use the fg command to resume a background job in the foreground. You can specify the job by its ID or PID:

# Resume job 1 in the foreground
fg %1

# Or by process ID
fg 12345

# Resume the most recent job (no argument)
fg

When you bring a job to the foreground, the shell blocks until that job completes or is suspended again.

Sending Jobs to the Background

The bg command resumes a suspended job in the background:

# Suspend a foreground job with Ctrl-Z, then:
bg %1   # Resume job 1 in the background

If the job is already running in the background, bg has no effect.

Process Substitution and Pipelines

Understanding Fish Pipelines

Fish pipelines connect the standard output of one command to the standard input of another using the pipe character |. Unlike Bash, Fish executes all commands in a pipeline simultaneously rather than sequentially. This is a significant behavioral difference:

# In Fish, both commands run concurrently
# Data flows through the pipe as it's produced
find /usr -name "*.log" | grep "error"

# The find command and grep run at the same time
# grep processes data as find discovers files

This concurrent execution model improves performance for long-running pipelines but means you cannot rely on sequential ordering within the pipeline itself.

Process Expansion for Substitution

Fish uses process expansion rather than the $() syntax for command substitution. The form (command) captures stdout:

# Process expansion — Fish's equivalent of $()
set file_count (ls | wc -l)
echo "There are $file_count files here"

# Nested process expansions work cleanly
set largest_files (ls -S | head -n (math 2 + 3))
echo "$largest_files"

Process expansion blocks until the subcommand completes, so it behaves like synchronous command substitution. The output is captured and can be assigned to variables or used inline.

Background Pipelines

You can run an entire pipeline in the background by appending &:

# Run a pipeline asynchronously
find / -name "*.tmp" | xargs rm -f &

# The entire pipeline gets a single job ID
jobs
# Output: Job 1: 'find / -name "*.tmp" | xargs rm -f' running

Waiting for Processes

The wait Command

Fish's wait builtin pauses execution until specified background jobs complete. You can wait for jobs by ID, by PID, or wait for all background jobs:

# Launch multiple background tasks
sleep 5 &
set pid1 $last_pid
sleep 10 &
set pid2 $last_pid
sleep 15 &
set pid3 $last_pid

echo "Waiting for all tasks to finish..."
wait $pid1 $pid2 $pid3
echo "All tasks completed!"

Waiting by job ID uses the % prefix:

# Wait for specific jobs
sleep 20 &        # Job 1
sleep 30 &        # Job 2

wait %1           # Wait only for job 1
echo "Job 1 finished"

wait %2           # Wait for job 2
echo "Job 2 finished"

Waiting with Timeouts

Fish's wait does not natively support timeouts, but you can implement timeout logic using a wrapper:

# Timeout wrapper for process waiting
function wait_with_timeout --argument pid timeout
    set start_time (date +%s)
    while kill -0 $pid 2>/dev/null
        set elapsed (math (date +%s) - $start_time)
        if test $elapsed -ge $timeout
            echo "Timeout reached, killing process $pid"
            kill $pid
            return 1
        end
        sleep 0.1
    end
    return 0
end

# Usage
slow_command &
set pid $last_pid
wait_with_timeout $pid 30
if test $status -eq 0
    echo "Process completed within timeout"
else
    echo "Process timed out and was killed"
end

Signal Management

Sending Signals with kill

Fish supports the standard kill command for sending signals to processes. You can use signal names or numbers:

# Send SIGTERM (default, signal 15)
kill 12345

# Send SIGKILL (signal 9)
kill -9 12345
# or
kill -KILL 12345

# Send SIGHUP to reload configuration
kill -HUP 12345

# Send SIGINT (equivalent to Ctrl-C)
kill -INT 12345

# Kill a job by job ID
kill %1

Listing Available Signals

You can see all available signals with:

# Print signal list
kill -l

# Typical output includes:
# HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT
# CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS

Trapping Signals in Fish Scripts

Fish handles signals through its event handler system rather than Bash's trap builtin. You define signal handlers using the function --on-signal flag:

# Define a handler for SIGINT (Ctrl-C)
function on_interrupt --on-signal INT
    echo "Interrupted! Cleaning up..."
    # Perform cleanup actions
    kill (jobs -p) 2>/dev/null  # Kill all child jobs
    exit 1
end

# Define a handler for SIGTERM
function on_terminate --on-signal TERM
    echo "Received termination signal, shutting down gracefully"
    # Save state, close files, etc.
    exit 0
end

# Main script logic
echo "Script running. Press Ctrl-C to interrupt."
while true
    echo "Working..."
    sleep 1
end

Multiple functions can be registered for the same signal. They execute in the order they were defined. To remove a handler, simply redefine the function or delete it:

# Remove a signal handler
functions --erase on_interrupt

Signal Propagation to Child Processes

When Fish receives a signal, it propagates that signal to all foreground child processes. Background processes are not automatically signaled — you must handle them explicitly in your handler:

function cleanup_children --on-signal INT --on-signal TERM
    echo "Terminating all child processes..."
    for pid in (jobs -p)
        kill -TERM $pid
    end
    wait
    exit 0
end

Process Groups and Sessions

Understanding Process Groups

Every process belongs to a process group. Fish automatically places each pipeline into its own process group. The foreground process group has controlling terminal access. Background process groups are denied terminal input by default (they receive SIGTTIN/SIGTTOU if they attempt terminal I/O).

You can inspect process group relationships using:

# Check process group of current shell
ps -o pid,pgid,sid,cmd -p $fish_pid

# See all processes in the current session
ps -o pid,pgid,sid,cmd -s (ps -o sid= -p $fish_pid)

Creating New Process Groups

Sometimes you want a child process to run in its own process group, isolating it from signals sent to the parent. You can achieve this with a small wrapper:

# Run a command in a new process group
function run_detached --argument cmd
    # Use setsid to create a new session (and thus a new process group)
    setsid $cmd &
    echo "Detached PID: $last_pid"
end

# Usage
run_detached "long_running_server"

Alternatively, you can launch a subprocess with explicit process group control:

# Start a process in a new process group using fish's job control
begin
    # This block runs in a subshell
    # Create a new process group
    exec setsid some_daemon &
end

Exit Status and Error Handling

Checking Exit Status

Fish stores the exit status of the last foreground command in the special variable $status. A status of 0 indicates success; any non-zero value indicates failure:

# Check exit status
cp source_file dest_file
if test $status -eq 0
    echo "Copy succeeded"
else
    echo "Copy failed with status $status"
end

For pipelines, $status reflects the exit status of the last command in the pipeline. To access individual exit statuses, Fish provides the $pipestatus array:

# Check each command's exit status in a pipeline
false | true | false
echo "Overall status: $status"        # 1 (last command failed)
echo "Pipe statuses: $pipestatus"     # 1 0 1

# Use pipestatus for detailed pipeline error handling
set statuses $pipestatus
for i in (seq 1 (count $statuses))
    echo "Command $i exited with status $statuses[$i]"
end

Collecting Exit Status of Background Jobs

Background jobs don't update $status immediately. Their exit status becomes available after you wait for them:

# Launch a background job that may fail
sleep 5; false &
set bg_pid $last_pid

echo "Background job running..."

# Wait for it and capture the exit status
wait $bg_pid
set bg_status $status
echo "Background job exited with status $bg_status"

Practical Examples

Example 1: Parallel File Processing

This script processes multiple log files concurrently, one process per file:

#!/usr/bin/env fish

function process_log --argument file
    echo "Processing $file..."
    # Simulate processing work
    sleep (random 1 5)
    set line_count (wc -l < $file)
    echo "$file: $line_count lines processed"
end

# Find all log files
set log_files (find /var/log -name "*.log" -type f)

# Launch parallel processing jobs
set pids
for file in $log_files
    process_log $file &
    set -a pids $last_pid
end

echo "Launched $(count $pids) processing jobs"

# Wait for all jobs to complete
for pid in $pids
    wait $pid
end

echo "All files processed!"

Example 2: Graceful Shutdown Handler

A robust server script that handles termination signals gracefully:

#!/usr/bin/env fish

set server_pid ""

function start_server
    echo "Starting server..."
    # Simulate a long-running server
    while true; sleep 1; echo "Server heartbeat"; end &
    set server_pid $last_pid
end

function shutdown_handler --on-signal INT --on-signal TERM
    echo "Shutdown signal received"
    if test -n "$server_pid"
        echo "Stopping server (PID $server_pid)..."
        kill -TERM $server_pid
        wait $server_pid
        echo "Server stopped"
    end
    echo "Cleanup complete, exiting"
    exit 0
end

start_server
echo "Server PID: $server_pid"
echo "Press Ctrl-C to stop"

# Wait for server to finish (or be killed)
wait $server_pid

Example 3: Process Pool with Concurrency Limit

Managing a pool of worker processes with a maximum concurrency limit:

#!/usr/bin/env fish

function worker --argument id duration
    echo "Worker $id starting (will run for $duration seconds)"
    sleep $duration
    echo "Worker $id finished"
end

set max_workers 4
set tasks (seq 1 10)   # 10 tasks to process
set running_pids

for task in $tasks
    set duration (random 2 8)
    
    # Wait if we've reached max concurrency
    while test (count $running_pids) -ge $max_workers
        # Check which workers have finished
        set still_running
        for pid in $running_pids
            if kill -0 $pid 2>/dev/null
                set -a still_running $pid
            end
        end
        set running_pids $still_running
        sleep 0.2
    end
    
    # Launch new worker
    worker $task $duration &
    set -a running_pids $last_pid
end

# Wait for remaining workers
for pid in $running_pids
    wait $pid
end

echo "All $count_tasks tasks completed with max $max_workers concurrent workers"

Example 4: Monitoring and Alerting on Process State

A process watchdog that monitors a critical service and restarts it if it fails:

#!/usr/bin/env fish

function critical_service
    echo "Critical service started (PID $fish_pid)"
    # Simulate occasional crashes
    while true
        sleep (random 2 10)
        if test (random 0 10) -eq 0
            echo "Service crash simulation"
            exit 1
        end
        echo "Service running normally"
    end
end

function watchdog --argument service_pid
    set max_restarts 5
    set restart_count 0
    
    while test $restart_count -lt $max_restarts
        if not kill -0 $service_pid 2>/dev/null
            set restart_count (math $restart_count + 1)
            echo "Service died! Restart attempt $restart_count of $max_restarts"
            
            # Launch new instance
            critical_service &
            set service_pid $last_pid
        end
        sleep 2
    end
    
    if test $restart_count -ge $max_restarts
        echo "Max restarts reached, giving up"
        return 1
    end
end

# Start service and watchdog
critical_service &
set svc_pid $last_pid

watchdog $svc_pid &

Best Practices for Fish Process Management

Always capture $last_pid immediately – After launching a background process with &, capture $last_pid right away before launching any other command that might overwrite it
Use wait for synchronization – When your script depends on background job completion, explicitly wait for those jobs rather than assuming they've finished
Register signal handlers early – Define --on-signal functions at the top of your script to ensure cleanup happens even if a signal arrives early
Clean up child processes – In signal handlers, iterate over jobs -p and kill remaining children to prevent orphaned processes
Prefer kill -TERM over kill -9 – SIGTERM allows processes to clean up gracefully. Reserve SIGKILL for processes that ignore SIGTERM
Check $pipestatus in pipelines – Don't rely solely on $status after pipelines; inspect $pipestatus when you need per-command exit information
Use process expansion for synchronous subcommands – The (command) syntax is cleaner and more readable than backtick-based substitution
Implement timeout logic for hanging processes – Fish's wait has no built-in timeout; wrap it with a polling loop when you need bounded wait times
Document your signal handling strategy – In complex scripts, add comments explaining which signals are trapped and what cleanup actions occur
Test with signals – Verify your script handles SIGINT, SIGTERM, and SIGHUP correctly by sending these signals during testing

Common Pitfalls and How to Avoid Them

Pitfall 1: Forgetting to Wait for Background Jobs

A script that exits before background jobs finish can leave orphaned processes or cause unexpected behavior:

# BAD: Script exits while background jobs are still running
process_file large_file.dat &
echo "Script done"   # Script ends here, background job may be orphaned

# GOOD: Explicitly wait for background jobs
process_file large_file.dat &
set pid $last_pid
wait $pid
echo "Processing complete, script done"

Pitfall 2: Race Conditions with $last_pid

The $last_pid variable is overwritten by every background launch. Capture it immediately:

# BAD: $last_pid may have changed
task_a &
task_b &
wait $last_pid   # This waits only for task_b!

# GOOD: Capture each PID
task_a &
set pid_a $last_pid
task_b &
set pid_b $last_pid
wait $pid_a; wait $pid_b

Pitfall 3: Assuming Sequential Pipeline Execution

Fish runs pipeline commands concurrently. Don't rely on one command finishing before another starts:

# Fish runs both commands simultaneously
# The left command's early output is available to the right command immediately
generate_data | process_data

# If you need strict sequential execution, use separate commands:
generate_data > temp_file
process_data < temp_file
rm temp_file

Pitfall 4: Ignoring Signal Propagation

When you press Ctrl-C, Fish sends SIGINT to the foreground process group. Background jobs are unaffected — they keep running unless you explicitly handle them:

# Without a signal handler, background jobs survive Ctrl-C
function cleanup --on-signal INT
    echo "Cleaning up background jobs..."
    for pid in (jobs -p)
        kill -TERM $pid
    end
    exit
end

long_task_a &
long_task_b &
wait

Advanced Process Management Techniques

Using fish_pid and fish_killme

Fish exposes its own process ID in $fish_pid. This is useful for self-referencing in scripts:

# Check if a Fish instance is the current one
if test "$fish_pid" = "$target_pid"
    echo "This is the target shell instance"
end

# Send a signal to the current Fish shell itself
# (fish_killme is an internal event, not a variable)
# Use kill on $fish_pid instead
echo "Shell PID: $fish_pid"

Process-Level Resource Limits

You can set resource limits for child processes using ulimit before launching them:

# Limit maximum memory for a child process (in KB)
ulimit -v 1048576  # 1 GB virtual memory limit
memory_intensive_task &

# Limit CPU time (in seconds)
ulimit -t 300      # 5 minute CPU time limit
cpu_bound_task &

Subshells and Process Isolation

Fish's begin...end blocks create subshells with isolated environments. Variables set inside a subshell don't leak to the parent:

# Subshell isolation
set global_var "outer"
begin
    set global_var "inner"
    echo "Inside: $global_var"   # Prints "inner"
end
echo "Outside: $global_var"      # Still prints "outer"

You can combine subshells with process management for clean task isolation:

# Run a task in an isolated subshell
begin
    set -l temp_dir (mktemp -d)
    cd $temp_dir
    # All operations stay in this directory
    download_and_process &
    set pid $last_pid
    wait $pid
    cd /
    rm -rf $temp_dir
end

Debugging Process Issues

Inspecting Process State

Fish provides several built-in tools for debugging process-related issues:

# List all child processes with their state
jobs -l

# Get detailed process information
ps aux | grep $fish_pid

# Check open file descriptors of a process
lsof -p $target_pid

# Trace system calls of a running process
strace -p $target_pid

# View process tree
pstree -p $fish_pid

Debugging Zombie Processes

Zombie processes occur when a child exits but its parent hasn't called wait to reap it. In Fish scripts, this typically happens when you launch background processes and the script exits without waiting:

# Detect zombie children
set zombie_count (ps -o state= -p (jobs -p) 2>/dev/null | grep Z | wc -l)
if test $zombie_count -gt 0
    echo "Warning: $zombie_count zombie processes detected"
end

# Prevent zombies by always waiting
function reap_all
    for pid in (jobs -p)
        wait $pid 2>/dev/null
    end
end

Conclusion

Fish shell process management combines the power of traditional Unix job control with a modern, streamlined syntax that reduces boilerplate and cognitive overhead. By understanding foreground and background execution, job control commands, signal handling through event-based functions, and the nuances of concurrent pipeline execution, you can write scripts that are both efficient and robust. The key takeaways are to always capture $last_pid immediately after launching background processes, use wait for synchronization, register comprehensive signal handlers with --on-signal, and respect Fish's concurrent pipeline model. With these patterns in your toolkit, Fish becomes an exceptionally capable shell for orchestrating complex multi-process workflows, from parallel data processing to resilient service management. The clean syntax and thoughtful design choices make process management in Fish not just powerful, but genuinely pleasant to work with.