I have to find all directory paths with specific subfolders.

The search pattern is as follows:

find /foo/*/searched_folder/bar -maxdepth 0 -type d

̶I̶t̶'̶s̶ ̶w̶o̶r̶k̶i̶n̶g̶ ̶p̶r̶e̶t̶t̶y̶ ̶w̶e̶l̶l̶ ̶w̶i̶t̶h̶ ̶f̶i̶n̶d̶ ̶i̶n̶ ̶v̶e̶r̶s̶i̶o̶n̶ ̶4̶.̶6̶,̶ ̶b̶u̶t̶ ̶h̶a̶v̶e̶ ̶t̶o̶ ̶u̶s̶e̶ ̶t̶h̶i̶s̶ ̶a̶l̶s̶o̶ ̶o̶l̶d̶e̶r̶ ̶4̶.̶5̶.̶1̶2̶.̶ ̶A̶n̶d̶ ̶t̶h̶a̶t̶'̶s̶ ̶w̶h̶e̶r̶e̶ ̶t̶h̶e̶ ̶p̶r̶o̶b̶l̶e̶m̶s̶ ̶s̶t̶a̶r̶t̶.̶ ̶ ̶ ̶I̶n̶ ̶t̶h̶e̶ ̶o̶l̶d̶e̶r̶ ̶v̶e̶r̶s̶i̶o̶n̶,̶ ̶a̶f̶t̶e̶r̶ ̶f̶i̶n̶d̶i̶n̶g̶ ̶t̶h̶e̶ ̶f̶i̶r̶s̶t̶ ̶e̶n̶t̶r̶y̶,̶ ̶t̶h̶e̶ ̶p̶r̶o̶g̶r̶a̶m̶ ̶s̶t̶o̶p̶s̶ ̶s̶e̶a̶r̶c̶h̶i̶n̶g̶ ̶a̶n̶d̶ ̶r̶e̶t̶u̶r̶n̶s̶ ̶o̶n̶l̶y̶ ̶o̶n̶e̶ ̶e̶n̶t̶r̶y̶. I̶ ̶w̶a̶s̶ ̶t̶r̶y̶i̶n̶g̶ ̶t̶o̶ ̶u̶s̶e̶ ̶o̶p̶t̶i̶o̶n̶ -prune b̶u̶t̶ ̶w̶i̶t̶h̶o̶u̶t̶ ̶s̶u̶c̶c̶e̶s̶s̶.̶ ̶I̶s̶ ̶t̶h̶e̶r̶e̶ ̶a̶n̶y̶ ̶e̶x̶t̶r̶a̶ ̶a̶r̶g̶u̶m̶e̶n̶t̶ ̶t̶o̶ ̶s̶e̶a̶r̶c̶h̶ ̶t̶h̶o̶s̶e̶ ̶f̶o̶l̶d̶e̶r̶ ̶p̶a̶t̶h̶s̶,̶ ̶o̶r̶ ̶m̶a̶y̶b̶e̶ ̶t̶h̶e̶r̶e̶ ̶i̶s̶ ̶s̶o̶m̶e̶ ̶o̶t̶h̶e̶r̶ ̶w̶a̶y̶ ̶t̶o̶ ̶s̶e̶a̶r̶c̶h̶ ̶i̶t̶?̶ ̶

I want find the directories that match the particular pattern, and integrate it into bash script as an path array. Everything is already working except search.

SORCE_ARRAY=($(find /projekte/*/$AB/software/software.git/ -maxdepth 0 -type d))

Real example

find /projekte/*/3140/software/software.git/ -maxdepth 0 -type d

New version (openSUSE Tumbleweed):


Older version (openSUSE Leap 15.1):



The problem are soft links. The structure on Linux openSUSE Tumbleweed does not distinguish whether it is a soft link or a regular folder on server. I thought that 3 folders exist, and it turned out that the last two results are soft links.

Meanwhile, on the openSUSE Leap is a different problem. Firstly almost all real folders are the first one, so I assumed that find doesn't look further. Secondly on the server the path in soft links doesn't look like:




This is unreadable for all system programs (not only for "find").

The conclusion is this:

  • Tumbleweed does not show whether the folder is a soft-link or a folder
  • Leap is not able to correctly interpret the soft link

And I still don't know how to combine this two things working together.

  • I would have expected both versions of GNU find to behave as in the second example that you show (returning multiple matches) as you give find multiple search paths. If the old version of GNU find did not do this, then it was a fault in that program. – Kusalananda Jul 1 at 9:55
  • Also, could you pleas clarify whether all you want is the directories that match the particular pattern that you have (you don't need find for this), or whether the actual command is more complex. – Kusalananda Jul 1 at 10:08
  • I want find the directories that match the particular pattern, and integrate it into bash script as an path array. Everything is already working except this bloody search. SORCE_ARRAY=($(find /projekte/*/$AB/software/software.git/ -maxdepth 0 -type d)) – RTS007 Jul 1 at 10:13
  • @Kusalananda Thanks to you, I noticed that the problem is not the find function, but the interpretation of soft links by the systems. – RTS007 Jul 1 at 18:10

To find all names that matches the pattern /projekte/*/3140/software/software.git/, you can do

set -- /projekte/*/3140/software/software.git/

The names are then available in the positional parameters:

for gitdir do
    printf 'Found directory %s\n' "$gitdir"

or just

printf 'Found directory %s\n' "$@"

This would print the names of the found directories. If any name is a symbolic link to a directory, then that symbolic link would be traversed.

If you need to assign these to a named array in e.g. bash:

set -- /projekte/*/3140/software/software.git/
SORCE_ARRAY=( "$@" )

or just

SORCE_ARRAY=( /projekte/*/3140/software/software.git/ )

This is the preferred way of doing this over expanding a command substitution as a command substitution would not preserve whitespace in filenames.

The only issue is if the pattern does not match anything in which case the pattern would be left unexpanded. To have a non-matching pattern expand to nothing at all, use shopt -s nullglob in the bash shell.

  • I'm running both on exactly the same set of filenames - it's the mounted server. Set function work's exactly the same as find. On first machine (OpenSUSE Tumbleweed) work good and find all paths, on 2nd (Leap 15.0), 3ed (Leap 15.1) and 4th (Leap 15.1) computer there it's only one path result. – RTS007 Jul 1 at 10:41
  • @RTS007 You don't actually use find for anything other than verifying that the names that the pattern expands to are names of directories, which they are since you end the pattern with a slash. The only possible issue with my answer is that if no directory matches the pattern, the pattern will remain unexpanded, which you can mitigate through shopt -s nullglob in bash. – Kusalananda Jul 1 at 10:46
  • Ah, so it's a network mounted share? Well that may mean there may well be other issues than a particular version of find. There may be caching issues or something else related to the serving of the network share. – Kusalananda Jul 1 at 10:49
  • Yes, it's network mounted share. Mounted with mount. Sorry that not mentioned before, I didn't expect it can influence. – RTS007 Jul 1 at 11:11
  • @RTS007 I've used NFS extensively before and experienced directories not showing up properly, even with local NFS mounts. – Kusalananda Jul 1 at 11:22

You should use the head command by piping your find, this way : find /foo/*/searched_folder/bar -maxdepth 0 -type d | head -n 1. This will only get you the first result.

  • Unfortunately, the head option doesn't work. It can limit the number of results in the latest version, but it does not help in finding all results in the older version. – RTS007 Jul 1 at 10:07
  • 2
    This is the exact opposite of what OP wants to do. – Panki Jul 1 at 10:24

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.