Find linux не выводить ошибки

Note:

• This answer probably goes deeper than the use case warrants, and find 2>/dev/null may be good enough in many situations. It may still be of interest for a cross-platform perspective and for its discussion of some advanced shell techniques in the interest of finding a solution that is as robust as possible, even though the cases guarded against may be largely hypothetical.

If your shell is bash or zsh, there’s a solution that is robust while being reasonably simple, using only POSIX-compliant find features; while bash itself is not part of POSIX, most modern Unix platforms come with it, making this solution widely portable:

find . > files_and_folders 2> >(grep -v 'Permission denied' >&2)

Note:

• If your system is configured to show localized error messages, prefix the find calls below with LC_ALL=C (LC_ALL=C find ...) to ensure that English messages are reported, so that grep -v 'Permission denied' works as intended. Invariably, however, any error messages that do get displayed will then be in English as well.

• >(...) is a (rarely used) output process substitution that allows redirecting output (in this case, stderr output (2>) to the stdin of the command inside >(...).
  In addition to bash and zsh, ksh supports them as well in principle, but trying to combine them with redirection from stderr, as is done here (2> >(...)), appears to be silently ignored (in ksh 93u+).

  • grep -v 'Permission denied' filters out (-v) all lines (from the find command’s stderr stream) that contain the phrase Permission denied and outputs the remaining lines to stderr (>&2).

  • Note: There’s a small chance that some of grep‘s output may arrive after find completes, because the overall command doesn’t wait for the command inside >(...) to finish. In bash, you can prevent this by appending | cat to the command.

This approach is:

• robust: grep is only applied to error messages (and not to a combination of file paths and error messages, potentially leading to false positives), and error messages other than permission-denied ones are passed through, to stderr.

• side-effect free: find‘s exit code is preserved: the inability to access at least one of the filesystem items encountered results in exit code 1 (although that won’t tell you whether errors other than permission-denied ones occurred (too)).

POSIX-compliant solutions:

Fully POSIX-compliant solutions either have limitations or require additional work.

If find‘s output is to be captured in a file anyway (or suppressed altogether), then the pipeline-based solution from Jonathan Leffler’s answer is simple, robust, and POSIX-compliant:

find . 2>&1 >files_and_folders | grep -v 'Permission denied' >&2

Note that the order of the redirections matters: 2>&1 must come first.

Capturing stdout output in a file up front allows 2>&1 to send only error messages through the pipeline, which grep can then unambiguously operate on.

The only downside is that the overall exit code will be the grep command’s, not find‘s, which in this case means: if there are no errors at all or only permission-denied errors, the exit code will be 1 (signaling failure), otherwise (errors other than permission-denied ones) 0 — which is the opposite of the intent.
That said, find‘s exit code is rarely used anyway, as it often conveys little information beyond fundamental failure such as passing a non-existent path.
However, the specific case of even only some of the input paths being inaccessible due to lack of permissions is reflected in find‘s exit code (in both GNU and BSD find): if a permissions-denied error occurs for any of the files processed, the exit code is set to 1.

The following variation addresses that:

find . 2>&1 >files_and_folders | { grep -v 'Permission denied' >&2; [ $? -eq 1 ]; }

Now, the exit code indicates whether any errors other than Permission denied occurred: 1 if so, 0 otherwise.
In other words: the exit code now reflects the true intent of the command: success (0) is reported, if no errors at all or only permission-denied errors occurred.
This is arguably even better than just passing find‘s exit code through, as in the solution at the top.

gniourf_gniourf in the comments proposes a (still POSIX-compliant) generalization of this solution using sophisticated redirections, which works even with the default behavior of printing the file paths to stdout:

{ find . 3>&2 2>&1 1>&3 | grep -v 'Permission denied' >&3; } 3>&2 2>&1

In short: Custom file descriptor 3 is used to temporarily swap stdout (1) and stderr (2), so that error messages alone can be piped to grep via stdout.

Without these redirections, both data (file paths) and error messages would be piped to grep via stdout, and grep would then not be able to distinguish between error message Permission denied and a (hypothetical) file whose name happens to contain the phrase Permission denied.

As in the first solution, however, the the exit code reported will be grep‘s, not find‘s, but the same fix as above can be applied.

Notes on the existing answers:

• There are several points to note about Michael Brux’s answer, find . ! -readable -prune -o -print:

  • It requires GNU find; notably, it won’t work on macOS. Of course, if you only ever need the command to work with GNU find, this won’t be a problem for you.

  • Some Permission denied errors may still surface: find ! -readable -prune reports such errors for the child items of directories for which the current user does have r permission, but lacks x (executable) permission. The reason is that because the directory itself is readable, -prune is not executed, and the attempt to descend into that directory then triggers the error messages. That said, the typical case is for the r permission to be missing.

  • Note: The following point is a matter of philosophy and/or specific use case, and you may decide it is not relevant to you and that the command fits your needs well, especially if simply printing the paths is all you do:

    • If you conceptualize the filtering of the permission-denied error messages a separate task that you want to be able to apply to any find command, then the opposite approach of proactively preventing permission-denied errors requires introducing «noise» into the find command, which also introduces complexity and logical pitfalls.
    • For instance, the most up-voted comment on Michael’s answer (as of this writing) attempts to show how to extend the command by including a -name filter, as follows:
      find . ! -readable -prune -o -name '*.txt'
      This, however, does not work as intended, because the trailing -print action is required (an explanation can be found in this answer). Such subtleties can introduce bugs.

• The first solution in Jonathan Leffler’s answer, find . 2>/dev/null > files_and_folders, as he himself states, blindly silences all error messages (and the workaround is cumbersome and not fully robust, as he also explains). Pragmatically speaking, however, it is the simplest solution, as you may be content to assume that any and all errors would be permission-related.

• mist’s answer, sudo find . > files_and_folders, is concise and pragmatic, but ill-advised for anything other than merely printing filenames, for security reasons: because you’re running as the root user, «you risk having your whole system being messed up by a bug in find or a malicious version, or an incorrect invocation which writes something unexpectedly, which could not happen if you ran this with normal privileges» (from a comment on mist’s answer by tripleee).

• The 2nd solution in viraptor’s answer, find . 2>&1 | grep -v 'Permission denied' > some_file runs the risk of false positives (due to sending a mix of stdout and stderr through the pipeline), and, potentially, instead of reporting non-permission-denied errors via stderr, captures them alongside the output paths in the output file.

you can filter out messages to stderr. I prefer to redirect them to stdout like this.

 find / -name art  2>&1 | grep -v "Permission denied"

Explanation:

In short, all regular output goes to standard output (stdout). All error messages to standard error (stderr).

grep usually finds/prints the specified string, the -v inverts this, so it finds/prints every string that doesn’t contain «Permission denied». All of your output from the find command, including error messages usually sent to stderr (file descriptor 2) go now to stdout(file descriptor 1) and then get filtered by the grep command.

This assumes you are using the bash/sh shell.

Under tcsh/csh you would use

 find / -name art |& grep ....

Модераторы: /dev/random, Модераторы разделов

[user@myhost ~]$ find / -name "*http_cache_*"
find: `/proc/tty/driver': Отказано в доступе
find: `/proc/1/task/1/fd': Отказано в доступе
find: `/proc/1/task/1/fdinfo': Отказано в доступе
find: `/proc/1/fd': Отказано в доступе
find: `/proc/1/fdinfo': Отказано в доступе
find: `/proc/2/task/2/fd': Отказано в доступе
.
.
.
/usr/share/kde4/services/http_cache_cleaner.desktop
.
.
.
find: `/usr/lib/mozilla/extensions': Отказано в доступе
.
.
.
/usr/lib/kde4/libexec/kio_http_cache_cleaner
/usr/lib/libkdeinit4_kio_http_cache_cleaner.so
find: `/lost+found': Отказано в доступе
find: `/boot/lost+found': Отказано в доступе

drb@localhost:~$ ( LANG=C; find /etc -name "XXX" )
find: /etc/cups/ssl: Permission denied
find: /etc/samba/private: Permission denied
find: /etc/openvpn/certs: Permission denied
find: /etc/openvpn/keys: Permission denied
find: /etc/bluetooth/passkeys: Permission denied
drb@localhost:~$ find /etc -name "XXX"
find: /etc/cups/ssl: Отказано в доступе
find: /etc/samba/private: Отказано в доступе
find: /etc/openvpn/certs: Отказано в доступе
find: /etc/openvpn/keys: Отказано в доступе
find: /etc/bluetooth/passkeys: Отказано в доступе

While running find command, received an error ‘ignore permission denied message from find’? We can help you.

Here at Bobcares, we have seen several such Linux-related errors as part of our Server Management Services for web hosts, Linux users, and online service providers.

Today we’ll take a look at the cause for this error and see how to fix it.

Find command basic syntax

For instance, the syntax is as follows:

find where-to-look criteria action
find /dir/to/search -name filetosearch
find /dir/to/search -name "*.c"
find /home/nixcraft/project/ -name "*.py" -print

In this example, find will search the /tmp directory for any files named “data*.txt” and display their pathnames:

find /path/to/dir -name "pattern" -print
find /tmp -iname "data*.txt"

OR

cd /tmp
find . -iname "data*.txt" -print

How we tackle ‘ignore permission denied message from find’

Now let’s take a look at how our Support Engineers tackle the error when executing the find command.

Recently, one of our customers was trying to execute the below find command in Linux/Unix and received “Permission denied” error messages.

find . -type d -name “bob”

So, we can hide or fix find command permission denied messages. Here is how we do it.

How to hide or fix find command permission denied messages

In the above example, we don’t have the read permission for vmware-root and orbit-Debian-gdm directories. So, we use the below syntax to avoid the problem.

## redirect error spam message to /dev/null ##
find where-to-look criteria action 2>/dev/null
find . -iname "data*.txt" -print 2>/dev/null

Here is the output without permission denied spam from find command:

./rtzip/data005.txt
./rtzip/data001.txt
./rtzip/data004.txt
./rtzip/data003.txt
./rtzip/data002.txt
./rtzip/data008.txt
./rtzip/data006.txt
./rtzip/data007.txt
./rtzip/data009.txt

Here, at the end of the find command 2>/dev/null tells the shell to redirect the error messages (FD #2) to /dev/null, so we don’t have to see them on screen. We use /dev/null to send any unwanted output from program/command. The system discards all data written on a /dev/null special file. To redirect standard error to /dev/null and store file list to output.txt, we type:

redirect error spam to /dev/null ##
find . -iname "data*.txt" -print 2>/dev/null > output.txt
cat output.txt

Exclude all “permission denied” messages from the “find” command on Linux

The one problem with the following command is that it would filter out all error messages created by the find command and not just the permission denied ones:

find / -name foo 2>/dev/null
find / -type d -name bar 2>/dev/null

In order to avoid that, we try the following find command along with grep command on Linux or Unix-like systems:

find / -name foo 2>&1 | grep -v "Permission denied"
find / -type d -name bar 2>&1 | grep -v "Permission denied"

Also, we can use the below syntax to skip “permission denied” errors messages when running find in Linux or Unix-based systems:

find /path/to/dir -name "search-patter" 2>&1 | grep -v "Permission denied"
find /etc -name "x*.conf" 2>&1 | grep -v "Permission denied"

To store output to a file, we run:

find /path/to/dir -name "search-patter" 2>&1 | grep -v "Permission denied" > output-file
find /etc -name "x*.conf" 2>&1 | grep -v "Permission denied" > output.txt

Then we display output.txt using the cat command:

cat output.txt

In the above example, we used the find command along with grep command to filter out permission denied error messages.

[Need any further assistance in Linux-related errors? – We’re available to help you]

Conclusion

In short, this error ‘ignore permission denied message from find’ occurs while running a ‘find’ command in Linux. Today, we saw how our Support Engineers resolve this error.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

The 2>/dev/null at the end of the find command tells your shell to redirect the standard error messages to /dev/null, so you won’t see them on screen. “/dev/null” is a virtual device file, Whatever you write to “/dev/null” will be discarded by the system.

Find command syntax

find {file_path} -type f -iname {file_pattern}

To discard the error “Permission Denied”

find infa/bdm/server/source/path -type f -iname "source_fname_*.txt" 2>&1 | grep -v "Permission denied"

To discard all type of error

find infa/bdm/server/source/path -type f -iname "source_fname_*.txt" 2>/dev/null