A Comprehensive Guide to Storing find Command Results as Arrays in Bash

In Bash scripting, storing the output of external commands as arrays is a common but error-prone operation. Particularly when dealing with file search commands like find, simple command substitution often leads to unexpected results due to filenames potentially containing special characters such as spaces and newlines. This article systematically addresses how to correctly store find command results as Bash arrays through a typical problem scenario.

Problem Analysis: Why Simple Array Assignment Fails

Many beginners attempt to store find results as arrays using the following approaches:

array=`find . -name "${input}"`

Or:

array=(`find . -name "${input}"`)

Both methods have fundamental issues. The first actually creates a string variable rather than an array. Even with the array syntax in the second approach, Bash performs word splitting on the output of find, using spaces, tabs, and newlines as default delimiters. This means if a filename contains spaces, it will be incorrectly split into multiple array elements.

For example, suppose there are two files in the current directory: file1.txt and my document.txt. Using the above methods, my document.txt would be split into two separate array elements: my and document.txt, which is clearly not the desired outcome.

Core Solution: Using the -print0 Option

To properly handle filenames with special characters, the -print0 option of the find command is essential. This option uses the null character (ASCII 0) as a delimiter between filenames. Since null characters are illegal in filenames, they can safely separate all filenames.

In Bash, reading null-delimited data requires the -d option of the read command. Here is the classic solution for Bash 4.3 and earlier versions:

array=()
while IFS= read -r -d $'\0'; do
    array+=("$REPLY")
done < <(find . -name "${input}" -print0)

This solution works as follows:

1. array=() creates an empty array
2. IFS= clears the Internal Field Separator to prevent additional word splitting
3. -r prevents backslash escape interpretation
4. -d $'\0' specifies the null character as the line terminator
5. array+=("$REPLY") appends the read filename to the array
6. Process substitution <(...) provides the output of find as input to the while loop

Simplified Solution for Bash 4.4+: The mapfile Command

Starting with Bash 4.4, the mapfile command (or its synonym readarray) supports the -d option, making the solution more concise:

mapfile -d $'\0' array < <(find . -name "${input}" -print0)

Or equivalently:

readarray -d '' array < <(find . -name "${input}" -print0)

Here, the empty string '' as the argument to -d indicates using the null character as the delimiter. This approach not only results in cleaner code but also typically offers better performance by avoiding loop overhead.

Alternative Method: Using the lastpipe Option

If process substitution cannot be used for some reason, consider the lastpipe option:

set +m
shopt -s lastpipe
array=()
find . -name "${input}" -print0 | while IFS= read -r -d $'\0'; do 
    array+=("$REPLY"); 
done
declare -p array

The lastpipe option causes the last command in a pipeline to execute in the current shell rather than a subshell. This ensures the array variable remains available after the pipeline executes. Note that lastpipe only takes effect when job control is disabled, hence the need for set +m first.

Solution for Simple Scenarios

If it is certain that filenames do not contain special characters like spaces or newlines, a simpler method can be used:

IFS=$'\n'
array=($(find . -name "${input}"))
unset IFS

This method sets the Internal Field Separator to newline and then performs command substitution. However, it must be emphasized that this approach is unsafe and should only be used in scenarios where filename formats are fully controlled.

Version Compatibility Considerations

In practical deployments, differences in Bash versions across systems must be considered:

• Linux systems typically use newer Bash versions (4.4+), allowing direct use of mapfile -d
• macOS systems, until recently, used Bash 3.2, requiring the while loop method
• If scripts need to run in multiple environments, version detection logic should be added

Here is a compatibility example:

if [[ ${BASH_VERSINFO[0]} -ge 4 ]] && [[ ${BASH_VERSINFO[1]} -ge 4 ]]; then
    mapfile -d $'\0' array < <(find . -name "${input}" -print0)
else
    array=()
    while IFS= read -r -d $'\0'; do
        array+=("$REPLY")
    done < <(find . -name "${input}" -print0)
fi

Practical Recommendations and Best Practices

In actual script development, the following best practices are recommended:

1. Always use -print0 when processing find output, unless it is absolutely certain that filenames contain no special characters
2. Use double quotes when referencing variables, such as "${array[@]}", to preserve element integrity
3. For cross-platform compatible scripts, use feature detection rather than version detection
4. Consider using printf "%s\n" "${array[@]}" to safely output array contents
5. In complex scripts, add appropriate error handling, such as checking the exit status of the find command

By understanding these technical details and best practices, developers can write more robust and reliable Bash scripts, correctly handling various edge cases and improving code quality and maintainability.