Ok I used find as follows

Result I get is
but I have in /etc many scripts which are related to vmware.
So why did find fail to find all those.

If I go to /etc/ and do

I do get the files here how ever as shown above when I use

/ (root directory) and not ./

I do not get the desired output.

I am using find as root and I was in $HOME.So why did find not give me the desired result?

How ever when I did
and went to / and used

I did get the desired result
But why did it not showed this result when I was in $HOME of root and used find as mentioned?

Hello tkmsr,

do you have any aliases which may change the behaviour of the find command. You may issue the command "alias" in order to list all available aliases.

With which distribution did you experience this issue? And do you remember that it worked as expected once before?

Markus

Try

1 members found this post helpful.

Markush I noticed this on Ubuntu server 10.04 bit.I regularly use find on my Ubuntu desktop which is 10.04 64 bit and different than.There are no aliases.So find is not new thing for me but this behavior is surely strange enough for me.I want to understand why this happened.

That's weird. It really should have worked. Anyway, I feel the find command is quite tedious. Instead, run "updatedb" as root/sudo, and then use the "locate" command.

1 members found this post helpful.

Hi,

I think this is a globbing issue. When you use
from within your $HOME directory then vmware* is first expanded by bash's globbing mechanism and then passed to 'find'. So if you have 'vmware-converter-distrib' then vmware* is expanded to that value and 'find' sees
If the globbing mechanism, however, does not find a match then it passes vmware* to find. Then 'find' performs its own pattern matching on the asterisk. If you want to use wildcards with 'find' then you should single- or double-quote the pattern or escape the wildcard like vmware\*.

To further explore this create two dummy files:
Now do try searching for them while in the same folder:
This will result in an error since file* is now expanded to
file1 file2
So this is what the command looks like when it is executed:
When you execute the command in the parent folder then 'find' will work as expected, i.e. if the parent folder does not contain any files that will be matched by bash's globbing mechanism.

3 members found this post helpful.

As usual, crts is on the money. Quotes will easily produce desired results

1 members found this post helpful.

You have to quote your wildcards so that they are passed to find instead of being interpreted by BASH first.

1 members found this post helpful.

I do not agree with you because I tried the same thing on a Ubuntu desktop edition (10.04 64 bit) and I used wildcard as I posted above and I see things working well without a problem.I did searched the way I expected in all subdirectories.
I feel some thing is seriously wrong with find on Ubuntu server edition.

0 members found this post helpful.

Did you also take your starting directory into consideration? I.e. were there any files that could have been matched and expanded by bash before they were passed to 'find'?
Also, could you check and post your shell options?

[EDIT]
I am specifically interested in the output of
echo $SHELLOPTS

Did you accidentally toggle the 'noglob' flag?

1 members found this post helpful.

Ok I am referring to the desktop edition where you asked for the results.
I am currently in a directory pwd shows
in this I have following
I did
from above directory
result
I had deliberately copied
links_to_practise.txt in /tmp to understand the problem I reported in this thread and results differ in the behaviour on server edition and desktop edition of Ubuntu 10.04 64 bit.

I don't see anything odd in that behavior. The asterisk can only expand to 'links_to_practise.txt' and nothing else. Create another file in the same directory and name it
'links_to_other_practise.txt'. Run
again and it should give an error under normal circumstances because now it will expand to 'links_to_practise.txt' and 'links_to_other_practise.txt' before it is passed to find.

See also my EDIT in my previous post.

2 members found this post helpful.

Ok I just tried what you said
Is this the error which you pointed?

Yes, your 'find' behaves as expected. This also means that the noglob flag is not set. Which should be the default. Now 'cd' into a directory that does NOT contain any file that starts with 'links_to_' and 'find' will succeed. As I explained earlier, if bash does not succeed to match and expand the wildcard it will pass 'link_to_*' to 'find'; with the asterisk! Then find's globbing mechanism will be able to treat the asterisk as wildcard in every directory it searches. You need to realize that there are in fact two globbing mechanisms involved here.
'Bash' and 'find'; both are capable of globbing.

2 members found this post helpful.

Awesome.This is great information I just tried what you said,in fact its one of its kind I had used it before but I did not knew this what you just said it did not gave any error this time.Even though I have used find many times but what you just told is simply awesome.