8

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. – Paddy Landau Sep 8 '14 at 10:13
  • A shot in the dark, but what about quoting? find "${SEARCH}" -print? – Alaa Ali Nov 22 '14 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. – Paddy Landau Nov 22 '14 at 20:38
8

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

WARNING:

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:

globstar
      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. – Paddy Landau Nov 22 '14 at 15:49
2

How about arrays?

$ tree Desktop/ Documents/
Desktop/
└── my folder
    └── more
        └── file
Documents/
└── 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! – Paddy Landau Nov 21 '14 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 '14 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 '14 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. – Paddy Landau Nov 21 '14 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! – Paddy Landau Nov 22 '14 at 15:47
0

I have finally found out the answer.

Add a backslash to all spaces:

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

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 '14 at 15:15
  • @terdon Thank you for the warning. Back to the drawing board! – Paddy Landau Nov 22 '14 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 '14 at 11:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.