Good research skills! Many people here are not at all able to independently come up with an at least valid try.

Alas, this line might even work, so when i tell you that there are a few problems with it - please believe me! I'll try to explain:

first problem: proper quoting

Code:

find $1

This will work as long as "$1" contains only "normal" paths, like "/some/dir". It will fail, though, when the path contains a space, because a space character is also used by the shell to delimit arguments. Consider the following two lines:

Code:

command arg1 arg2 arg3
command arg1 "arg2 arg3"

the first command gets 3 arguments, "arg1", "arg2" and "arg3". The second command only gets two: "arg1" and "arg2 arg3". The double quote in this case tells the shell to treat the blank like a normal character. Because it won't hurt script programmers routinely protect their variables:

Code:

find "$1"

next problem: where do you want to search?

"find" is a command which searches recursively. That is, it finds files not only in the directory it starts in, but in every subdirectory there might be too. Do you want that? Or do you want to only search in the directory you named? Depending on your answer you may have to either modify "find" (read the man page about the "-prune"-option) to only search this directory and not its subdirectories or use "ls" instead of find.

last problem: subshell invocation

it is possible to invoke a series of commands and fill their output to a variable. Historically this has been done with backticks, like you did. Still, backticks have some severe limitations and are deprecated. Instead there is the "$(...)". Alas, there are still a lot of examples on the net with backticks. Believe me, they are all flawed in this regard. Backticks do not offer a single advantage over the modern subshell invocation but a lot of disadavantages: cannot be nested, cannot be quoted, just to name two. Therefore:

Code:

getFile="$(find "$1" -type f -name '*.in')"

I hope this helps.

bakunin