How to remove "find: cannot open"

[Javier_45]

Hello guys,
I know this may sound a very silly question but whenever you are doing a find, and you don't have acess to a certain directory, you always get these kind messages:

find: cannot open ./etc/opt/...
find: cannot open ./etc/opt/resmon/...

How can I get rid of them so I will only display the files/directories that match my find?

Thanks a lot,

Javier

[Pete Randall]

Javier,

Pipe your find to a "grep -v cannot".


Pete

[Rick Garland]

If you are unable to open these areas, how do you know the find searched everywhere is could?

The messages 'cannot open' signify a permission issue. Doing the find as a non-root user.

If true, the other option is to have find skip the areas it cannot open then those messages will not appear.

[A. Clay Stephenson]

All find's error messages go to stderr so the solution is simply:

find . -print 2>/dev/null

[Javier_45]

Thank you guys!

[Javier_45]

Actually I still get the pesky messages with either

find . -name "*.bsf" -exec grep -v "cannot" {} \;

or

find . -name "*.bsf" | grep -v cannot

find: cannot open ./etc/opt/resmon/persistence
find: cannot open ./etc/opt/resmon/pipe
find: cannot open ./etc/opt/sanmgr
find: cannot open ./etc/opt/hpsmc
find: cannot open ./etc/sam/custom

[Pete Randall]

My mistake, Javier. I think that's because those are stderr messages, as Clay points out, and therefore not passed as stdin to grep. That's my theory anyway.


Pete

[A. Clay Stephenson]

Of course you do. Grep is working on stdout but the error messages are going to stderr. Normally, stdout and stderr are directed to a common device (your terminal). Redirest stderr to /dev/null and the error messages will disappear.

[Biswajit Tripathy]

As already suggested above, the "cannot open" error
messages go to stderr and pipe works on stdout, so
they still show up in your output. There are 2 solutions
to this. One, you could follow Clay's suggestion of
directing stderr to /dev/null. The other option is to
redirect stderr to stdout and then use "grep -v" to
remove the error messages.

# find . -name "*.bsf" 2>&1 | grep -v cannot

- Biswajit

[Amit Agarwal_1]

REdirecting the error message to /dev/null will be faster than using grep.

$ find 2>/dev/null

this is the best way suited for your need.

[Muthukumar_5]

If you are using HFS file system then you can use -acl option with find to remove error messages as cannot open.. as,

find -acl '%.%, +r'

Else redirect all error messages to /dev/null simply as,

find 2>/dev/null

HTH.

[Javier_45]

Thanks a lot to all of you!

[Stephen Keane]

Biswajit's solution does have the benefit that any other errors (other than those containing the word 'cannot') are visible, should you wish to see them; otherwise direct stderr to /dev/null.

[A. Clay Stephenson]

On the other hand, the grep approach also has the unwanted side effect of filtering out any pathnames which happen to contain "cannot". You would be much better served to separate stdout and stderr and if you are interested in the error messages then capture stderr to a file and process it separately.

[Biswajit Tripathy]

A Clay Stephenson wrore:
> On the other hand, the grep approach also has
> the unwanted side effect of filtering out any
> pathnames which happen to contain "cannot".

Yes. That could, ofcourse, be fixed with couple of
extra lines of script.

> You would be much better served to separate
> stdout and stderr and if you are interested in the
> error messages then capture stderr to a file and
> process it separately.

Agreed 100%. If the programmer wrote different
things to stdout and stderr, then it was for a reason.

- Biswajit