I want to use find to find files in a set of folders restricted by wildcards, but where there are spaces in the path name.

From the command line, this is easy. The following examples all work.

find  te*/my\ files/more   -print
find  te*/'my files'/more  -print
find  te*/my' 'files/more  -print

These will find files in, for example, terminal/my files/more and tepid/my files/more.

However, I need this to be part of a script; what I need is something like this:

SEARCH='te*/my\ files/more'
find ${SEARCH} -print

Unfortunately, whatever I do, I don't seem to be able to mix wildcards and spaces in a find command within a script. The above example returns the following errors (note the unexpected doubling of the backslash):

find: ‘te*/my\\’: No such file or directory
find: ‘files/more’: No such file or directory

Trying to use quotes also fails.

SEARCH="te*/'my files'/more"
find ${SEARCH} -print

This returns the following errors, having ignored the meaning of the quotes:

find: ‘te*/'my’: No such file or directory
find: ‘files'/more’: No such file or directory

Here's one more example.

SEARCH='te*/my files/more'
find ${SEARCH} -print

As expected:

find: ‘te*/my’: No such file or directory
find: ‘files/more’: No such file or directory

Every variation that I've tried returns an error.

I have a workaround, which is potentially dangerous because it returns too many folders. I convert all spaces to a question mark (single-character wildcard) like this:

SEARCH='te*/my files/more'
SEARCH=${SEARCH// /?}       # Convert every space to a question mark.
find ${SEARCH} -print

This is the equivalent of:

find te*/my?files/more -print

This returns not only the correct folders but also terse/myxfiles/more, which it's not supposed to.

How can I achieve what I'm trying to do? Google has not helped me :(

  • @KasiyA I'm using bash; you must be using something else, as I've not seen that construction before. The command results in SEARCH: command not found with the command find -print being executed. Sep 8, 2014 at 10:13
  • A shot in the dark, but what about quoting? find "${SEARCH}" -print?
    – Alaa Ali
    Nov 22, 2014 at 15:48
  • @AlaaAli No, it doesn't work, because quoting prevents Bash from using the wildcards. It will look for a path specifically with the name (in my example) te*/'my files'/more. Nov 22, 2014 at 20:38

4 Answers 4


The exact same command should work fine in a script:

#!/usr/bin/env bash
find  te*/my\ files/ -print

If you need to have it as a variable, it gets a bit more complex:

#!/usr/bin/env bash
search='te*/my\ files/'
eval find "$search" -print


Using eval like that is not safe and can result in executing arbitrary and possibly harmful code if your file names can contain certain characters. See bash FAQ 48 for details.

It's better to pass the path as an argument:

#!/usr/bin/env bash
find "$@" -name "file*"

Another approach is to avoid find altogether and use bash's extended globbing features and globs:

#!/usr/bin/env bash
shopt -s globstar
for file in te*/my\ files/**; do echo "$file"; done

The globstar bash option lets you use ** to match recursively:

      If set, the pattern ** used in a pathname expansion con‐
      text will match all files and zero or  more  directories
      and  subdirectories.  If the pattern is followed by a /,
      only directories and subdirectories match.

To make it act 100% like find and include dotfiles (hidden files), use

#!/usr/bin/env bash
shopt -s globstar
shopt -s dotglob
for file in te*/my\ files/**; do echo "$file"; done

You can even echo them directly without the loop:

echo te*/my\ files/**
  • 2
    I have set this as the answer because of the helpful comments that terdon has made (not forgetting the helpful comments from others). I have used Bash's globbing ability on the command line to pass multiple paths to my script, instead of the script trying to sort it out. It works well. Nov 22, 2014 at 15:49

How about arrays?

$ tree Desktop/ Documents/
└── my folder
    └── more
        └── file
└── my folder
    ├── folder
    └── more

5 directories, 1 file
$ SEARCH=(D*/my\ folder)
$ find "${SEARCH[@]}" 
Desktop/my folder
Desktop/my folder/more
Desktop/my folder/more/file
Documents/my folder
Documents/my folder/more
Documents/my folder/folder

(*) expands into an array of whatever matches the wildcard. And "${SEARCH[@]}" expands into all the elements in the array ([@]), with each individually quoted.

Belatedly, I realise find itself should be capable of this. Something like:

find . -path 'D*/my folder/more/'
  • Clever idea, but alas, it doesn't work. Why? Because the path itself is held in a variable; hence, INPUTPATH='te*/my files/more and SEARCH=(${INPUTPATH}). No matter how I vary the way I do this, I still end up with a non-functional result. This seems impossible! Nov 21, 2014 at 14:04
  • This is all true of course, but the OP needs to do it in a script. That changes things since the expansion of wildcards gets significantly more complex and this doesn't work.
    – terdon
    Nov 21, 2014 at 14:05
  • @PaddyLandau In which case, why can you not use find's -path filter? It uses wildcards and definitely does not need expansion.
    – muru
    Nov 21, 2014 at 14:30
  • @muru That's interesting; I didn't know about -path. In the past 10 minutes, though, I have figured out the answer: use eval! It seems to be simpler than -path. Nov 21, 2014 at 14:49
  • 2
    @terdon and muru and everybody: Thank you. I have heard what you have all said, and I realised that I should be making my script do one thing, and letting Bash globbing pass multiple files or paths to the script. I have modified my script thus. It works well and fits better with the Linux philosophy. Thank you again! Nov 22, 2014 at 15:47

It's a little dated now but, if that can help anybody with this question, using RE's collating symbol [[.space.]] without quoting $SEARCH variable within find command line arguments, is working as long as there's no special characters into the expanded path-names in place of the asterisk.

set -x
mkdir -p te{flon,nnis,rrine}/my\ files/more
find $SEARCH

give the following results:

+ mkdir -p 'teflon/my files/more' 'tennis/my files/more' 'terrine/my files/more'
+ SEARCH='te*/my[[.space.]]files/more'
+ find 'teflon/my files/more' 'tennis/my files/more' 'terrine/my files/more'
teflon/my files/more
tennis/my files/more
terrine/my files/more

To prevent globing unwanted chars, One can replace the asterisk (*) by any collating elements (characters):

set -x
mkdir -p -- te{,-,_}{flon,nnis,rrine}/my\ files/more
find $SEARCH

giving the following results:

+ mkdir -p -- 'teflon/my files/more' 'tennis/my files/more' 'terrine/my files/more' \
'te-flon/my files/more' 'te-nnis/my files/more' 'te-rrine/my files/more' \
'te_flon/my files/more' 'te_nnis/my files/more' 'te_rrine/my files/more'
+ SEARCH='te[[:alnum:][.space.][.hyphen.][.underscore.]]*/my[[.space.]]files/more'
+ find 'te-flon/my files/more' 'te_flon/my files/more' 'teflon/my files/more' \
'te-nnis/my files/more' 'te_nnis/my files/more' 'tennis/my files/more' \
'te-rrine/my files/more' 'te_rrine/my files/more' 'terrine/my files/more'
te-flon/my files/more
te_flon/my files/more
teflon/my files/more
te-nnis/my files/more
te_nnis/my files/more
tennis/my files/more
te-rrine/my files/more
te_rrine/my files/more
terrine/my files/more

Note that to shorten the line, [.hyphen.] can be replaced by either [.-.] or - and [.underscore.] can be replaced by either [._.] or _.

Truncating lines with backslashes (\) added by myself for readability purpose.


I have finally found out the answer.

Add a backslash to all spaces:

SEARCH='te*/my files/more'

At this point, SEARCH contains te*/my\ files/more.

Then, use eval.

eval find ${SEARCH} -print

It's that simple! Using eval bypasses the interpretation that ${SEARCH} is from a variable.

  • Please don't..
    – terdon
    Nov 21, 2014 at 15:15
  • @terdon Thank you for the warning. Back to the drawing board! Nov 22, 2014 at 10:55
  • Yeah, this is surprisingly tricky. I just updated my answer with another approach, why not use globbing instead? If that still doesn't work, I suggest you post a new question on Unix & Linux explaining what your final objective is and why you need to have the pattern as a variable. This type of thing is likelier to get a better answer there.
    – terdon
    Nov 22, 2014 at 11:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .