183

I am trying to save the result from find as arrays. Here is my code:

#!/bin/bash

echo "input : "
read input

echo "searching file with this pattern '${input}' under present directory"
array=`find . -name ${input}`

len=${#array[*]}
echo "found : ${len}"

i=0

while [ $i -lt $len ]
do
echo ${array[$i]}
let i++
done

I get 2 .txt files under current directory. So I expect '2' as result of ${len}. However, it prints 1. The reason is that it takes all result of find as one elements. How can I fix this?

P.S
I found several solutions on StackOverFlow about a similar problem. However, they are a little bit different so I can't apply in my case. I need to store the results in a variable before the loop. Thanks again.

0

10 Answers 10

216

Update 2020 for Linux Users:

If you have an up-to-date version of bash (4.4-alpha or better), as you probably do if you are on Linux, then you should be using Benjamin W.'s answer.

If you are on Mac OS, which —last I checked— still used bash 3.2, or are otherwise using an older bash, then continue on to the next section.

Answer for bash 4.3 or earlier

Here is one solution for getting the output of find into a bash array:

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

This is tricky because, in general, file names can have spaces, new lines, and other script-hostile characters. The only way to use find and have the file names safely separated from each other is to use -print0 which prints the file names separated with a null character. This would not be much of an inconvenience if bash's readarray/mapfile functions supported null-separated strings but they don't. Bash's read does and that leads us to the loop above.

[This answer was originally written in 2014. If you have a recent version of bash, please see the update below.]

How it works

  1. The first line creates an empty array: array=()

  2. Every time that the read statement is executed, a null-separated file name is read from standard input. The -r option tells read to leave backslash characters alone. The -d $'\0' tells read that the input will be null-separated. Since we omit the name to read, the shell puts the input into the default name: REPLY.

  3. The array+=("$REPLY") statement appends the new file name to the array array.

  4. The final line combines redirection and command substitution to provide the output of find to the standard input of the while loop.

Why use process substitution?

If we didn't use process substitution, the loop could be written as:

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

In the above the output of find is stored in a temporary file and that file is used as standard input to the while loop. The idea of process substitution is to make such temporary files unnecessary. So, instead of having the while loop get its stdin from tmpfile, we can have it get its stdin from <(find . -name ${input} -print0).

Process substitution is widely useful. In many places where a command wants to read from a file, you can specify process substitution, <(...), instead of a file name. There is an analogous form, >(...), that can be used in place of a file name where the command wants to write to the file.

Like arrays, process substitution is a feature of bash and other advanced shells. It is not part of the POSIX standard.

Alternative: lastpipe

If desired, lastpipe can be used instead of process substitution (hat tip: Caesar):

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

shopt -s lastpipe tells bash to run the last command in the pipeline in the current shell (not the background). This way, the array remains in existence after the pipeline completes. Because lastpipe only takes effect if job control is turned off, we run set +m. (In a script, as opposed to the command line, job control is off by default.)

Additional notes

The following command creates a shell variable, not a shell array:

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

If you wanted to create an array, you would need to put parens around the output of find. So, naively, one could:

array=(`find . -name "${input}"`)  # don't do this

The problem is that the shell performs word splitting on the results of find so that the elements of the array are not guaranteed to be what you want.

Update 2019

Starting with version 4.4-alpha, bash now supports a -d option so that the above loop is no longer necessary. Instead, one can use:

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

For more information on this, please see (and upvote) Benjamin W.'s answer.

Sign up to request clarification or add additional context in comments.

31 Comments

@JuneyoungOh Glad it helped. I added a section of process substitution.
@Rockallite That is a good observation but incomplete. While it is true that we don't split into multiple words, we still need IFS= to avoid removal of whitespace from the beginnings or ends of the input lines. You can test this easily by comparing the output of read var <<<' abc '; echo ">$var<" with the output of IFS= read var <<<' abc '; echo ">$var<". In the former case, the spaces before and after abc are removed. In the latter, they aren't. File names that begin or end with whitespace may be unusual but, it they exist, we want them processed correctly.
Hi, after i execute your code i get message syntax error near unexpected token <' done < <(find aaa/ -not -newermt "$last_build_timestamp_v" -type f -print0)'
A note: the simpler '' can be used instead of $'\0': n=0; while IFS= read -r -d '' line || [ "$line" ]; do echo "$((++n)):$line"; done < <(printf 'first\nstill first\0second\0third')
@theeagle I assume that you intended to write BLAH=$(find . -name '*.php'). As discussed in the answer, that approach will work in limited cases but it won't work in general with all filenames and it doesn't produce, as the OP expected, an array.
|
141

Bash 4.4 introduced a -d option to readarray/mapfile, so this can now be solved with

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

for a method that works with arbitrary filenames including blanks, newlines, and globbing characters. This requires that your find supports -print0, as for example GNU find does.

From the manual (omitting other options):

mapfile [-d delim] [array]

-d
The first character of delim is used to terminate each input line, rather than newline. If delim is the empty string, mapfile will terminate a line when it reads a NUL character.

And readarray is just a synonym of mapfile.

5 Comments

This is great, I've already given it a +1. There's one caveat though -- if the command inside the process substitution fails, the exit code of the overall command is still 0. Is there a good way to have the exit code propagated to the outer command?
@dpritch Inspired by this answer, you could print the exit status as part of the process substitution: readarray -d '' array < <(find . -name "$input" -print0; printf "$?"), and then examine the last array element: echo "${array[-1]}".
^^ This is brilliant!
Why is -print0 necessary when it seems sufficient to enclose the find command in double quotes to handle filenames with special chars (even double quotes), like so: `files=("$(find -type f)").
@markling It's necessary because filenames are allowed to include linebreaks; the null byte is the only character that can't possibly appear in a filenmae. Two good references for this: Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems, Filenames and Pathnames in Shell: How to do it Correctly
45

The following appears to work for both Bash and Z Shell on macOS.

#! /bin/sh

IFS=$'\n'
paths=($(find . -name "foo"))
unset IFS

printf "%s\n" "${paths[@]}"

6 Comments

This works with files having spaces and other special characters, fails with the (admittedly rare) case of files having a linebreak in their name. You can create one for a test with printf "%b" "file name with spaces, a star * ...\012and a second line\0" | xargs -0 touch
maybe I'm missing something here, but this seems like the much clearer, easier solution for 99% of cases
Definitely works great for zsh on macOS Big Sur :) thanks! - but I also know my fileset has no names with newlines, because who does that? I have never seen one in the wild and I made the files so I know its not an issue.
Newlines are an issue in case the script may operate on files that are supplied by a potentially malicious user. For a hypothetical example, if your system ran something like detect-malware "${paths[@]}", a virus could be smuggled past this defense by including a newline in its name.
|
24

If you are using bash 4 or later, you can replace your use of find with

shopt -s globstar nullglob
array=( **/*"$input"* )

The ** pattern enabled by globstar matches 0 or more directories, allowing the pattern to match to an arbitrary depth in the current directory. Without the nullglob option, the pattern (after parameter expansion) is treated literally, so with no matches you would have an array with a single string rather than an empty array.

Add the dotglob option to the first line as well if you want to traverse hidden directories (like .ssh) and match hidden files (like .bashrc) as well.

5 Comments

Maybe nullglob too…
Yeah, I always forget that.
Note that this will not include the hidden files and directories, unless dotglob is set (this may or may not be wanted, but it's worth mentioning too).
This looks very useful, unless you actually need find's more interesting file matching features which aren't name glob based (for example, find by type, date, etc).
Indeed. find still has it uses (unless you are using zsh, in which case I think just about anything find can do you can do with some unreadable set of glob qualifiers :) )
14

you can try something like

array=(`find . -type f | sort -r | head -2`)
, and in order to print the array values , you can try something like echo "${array[*]}"

2 Comments

Breaks if there are filenames with spaces or glob characters.
You should copy/paste that into shellcheck.net and fix the issues it'll tell you about.
5

The suggested solutions are nice but I think that nobody mentioned the most simple and trivial solution.

This:

jars_home=/home/xxx/jars
files=($(find "$jars_home" -type f -name "*.jar"))

It uses the standard bash array declaration syntax:

myArray=("red" "yellow" "blue" "green")

Then:

  • array length: echo ${#files[@]} # 2
  • 1st element: echo ${files[0]} # /home/xxx/jars/hello.jar
  • 2nd element: echo ${files[1]} # /home/xxx/jars/something-else.jar
  • print the array elements: printf '%s\n' "${files[@]}"

6 Comments

This is the way!
That'll fail given various characters in the file names it finds, the contents of the directory you run it from, environment settings, etc. as mentioned in comments to other similar answers, e.g. stackoverflow.com/a/31847896/1745001. It's not doing myArray=("red *" "yellow" "blue" "green") as you think (I added the * to show the globbing issue), it's doing myArray=(red * yellow blue green) which has very different results.
@EdMorton I think that you misunderstood something here. If you would like to use joker characters in your find command then you must add it after the -name param. The array with color names is just an example result, nothing else.
You need to use readarray -d '' files < <(find "$jars_home" -type f -name "*.jar" -printf '%p\0') or similar to robustly populate files[] with the output of find.
Thanks for the correction/help/explanation. I will update the code in my post accordingly.
|
2

None of these solutions suited me because I didn't feel like learning readarray and mapfile. Here is what I came up with.

#!/bin/bash

echo "input : "
read input

echo "searching file with this pattern '${input}' under present directory"
# The only change is here. Append to array for each non-empty line.
array=()
while read line; do
    [[ ! -z "$line" ]] && array+=("$line")
done; <<< $(find . -name ${input} -print)

len=${#array[@]}
echo "found : ${len}"

i=0

while [ $i -lt $len ]
do
echo ${array[$i]}
let i++
done

2 Comments

I like this one. But shellcheck asked me to remove the semicolon in this line done; <<<
You should copy/paste that into shellcheck.net and fix the issues it'll tell you about.
-1

Long way but it works for me...

findCms=$(find -name <name>)
IFS=' ' read -ra arr <<< $findCms
for i in "${arr[@]}"; do
  echo "$i"
done

another way...

findCmd=$(find -name text-to-find -print)
while IFS= read -r line; do
    echo "Line: $line"
done <<< "$findCmd"

1 Comment

You should copy/paste that into shellcheck.net and fix the issues it'll tell you about.
-2

You could do like this:

#!/bin/bash
echo "input : "
read input

echo "searching file with this pattern '${input}' under present directory"
array=(`find . -name '*'${input}'*'`)

for i in "${array[@]}"
do :
    echo $i
done

1 Comment

Thanks. a lot. But as @anishsane pointed, empty spaces in filename should be considered in my program. Anyway Thanks!
-3

In bash, $(<any_shell_cmd>) helps to run a command and capture the output. Passing this to IFS with \n as delimiter helps to convert that to an array.

IFS='\n' read -r -a txt_files <<< $(find /path/to/dir -name "*.txt")

2 Comments

This will get only the first file of the results of find into the array.
You should copy/paste that into shellcheck.net and fix the issues it'll tell you about.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.