How to Use the yes Command in Linux to Automate Prompts and Stress Test Systems

In Unix and Linux systems, automating repetitive command-line interactions is fundamental to efficient administration. When running legacy scripts, installer packages, or bulk file management tasks, programs often prompt the user repeatedly with interactive confirmation dialogues such as “Are you sure? [y/N]”. While modern package managers like APT offer flags like -y, many scripts and tools lack unattended automation switches.

The GNU yes command is an ancient yet remarkably versatile utility included in every Linux distribution. At its core, yes continuously outputs an affirmative string (or any custom text) until terminated. When piped into other commands, it instantly satisfies interactive terminal prompts without human intervention. Additionally, system administrators leverage its blazing throughput for CPU stress testing and hardware benchmarking. In this guide, we explore how to use the yes command in Linux, automate confirmations, and test system stability.

How the yes Command Works

Written by David MacKenzie in the early days of GNU, yes is designed for extreme computational simplicity. It writes a string followed by a newline directly to the standard output buffer in an infinite loop. Unlike shell-based while true; do echo y; done loops—which suffer massive interpreter overhead—the compiled C implementation of yes operates at hardware memory bandwidth speeds, outputting gigabytes of text per second.

Basic Syntax and Default Output

When invoked without arguments, yes repeatedly prints the letter y followed by a newline:

yes

Your terminal window will immediately fill with an endless stream of y characters scrolling at high speed. To stop the command, press Ctrl + C.

Outputting Custom Strings and Negative Confirmations

You are not limited to the letter “y”. Passing any string or series of words after the command causes yes to repeat that specific phrase indefinitely:

To output an affirmative word:

yes accept

To output a negative response for commands that default to yes but require automated refusal:

yes n

To output a multi-word phrase:

yes "Confirm deployment to staging"

Automating Interactive Prompts in Pipelines

The most common administrative use case for yes is piping its output into an interactive utility that demands confirmation for every processed item.

Example 1: Bulk Deletion with Confirmation Override

If you run rm -i *.bak, the shell prompts you to confirm the deletion of every single backup file. To bypass the prompt without removing the safety alias permanently:

yes | rm -i *.bak

The piped yes feeds an immediate “y” followed by Enter into each prompt as it appears.

Example 2: Automating Git Patch Application

When executing scripts or compiling custom software that prompts for license acceptance or module selection:

yes "" | ./configure_script.sh

Passing an empty string (yes "") continuously sends the Enter key, accepting the default values on every prompt.

Example 3: Overriding Overwrite Warnings in File Extraction

yes | unzip archive.zip

Automatically answers “yes” to replace all conflicting files during zip extraction.

Stress Testing CPU Cores and Thermal Throttling

Because yes executes a tight, unthrottled C loop writing to /dev/null, it can saturate an entire processor core to 100% capacity without creating disk I/O bottlenecks. System builders and overclockers use this to test heatsink thermal dissipation and fan curves:

To saturate a single CPU core at 100%:

yes > /dev/null &

To saturate all CPU cores simultaneously on a multi-core server (e.g. an 8-core CPU):

for i in $(seq 1 $(nproc)); do yes > /dev/null & done

Open top or htop in another terminal window to observe all CPU cores pegged at 100% utilisation. When your thermal testing is complete, terminate all running yes instances in one command:

killall yes

Generating Massive Test Files and Pipeline Benchmarks

If you need to generate a dummy 1 GB file instantly to test disk write speeds, filesystem quotas, or network transfers, combining yes with head provides an efficient alternative to dd:

yes "SAMPLE_DATA_ROW_FOR_TESTING" | head -n 1000000 > test_dataset.txt

To benchmark how fast your terminal emulator or CPU can process stream pipelines, combine yes with the pipe viewer utility (pv):

yes | pv > /dev/null

On modern hardware, this typically reports data throughput exceeding 3.5 to 5.0 GiB/s, giving an accurate benchmark of memory bandwidth.

Safety Warnings and Avoiding Infinite Loops

• Beware of Destructive Automation: Piped confirmations like yes | rm -i provide zero human review. If your file glob matches unintended critical directories, the deletion is permanent and irreversible. Always verify your file lists with ls before piping yes.
• Broken Pipes (SIGPIPE): When the receiving program (such as head or unzip) finishes and closes its input stream, the operating system sends a SIGPIPE signal to yes, causing it to terminate cleanly without hanging in the background.
• Background Process Leaks: If you launch yes > /dev/null & for CPU testing, remember that closing your terminal window will not always terminate background jobs. Always run killall yes before logging out of remote SSH sessions.