Using grep with pipe and ampersand to filter errors from find
I am using cygwin to find a file on the cygdrive.
However I need to suppress the permission denied messages (otherwise the results get hidden in the error messages). The following command works:
find -name 'myfile.*' |& grep -v "Permission denied"
I don't understand why the ampersand needs to be put into this command, would have expected this to work but it doesn't.
find -name 'myfile.*' | grep -v "Permission denied"
Please explain the meaning of the ampersand.
bash command-line find grep
add a comment |
I am using cygwin to find a file on the cygdrive.
However I need to suppress the permission denied messages (otherwise the results get hidden in the error messages). The following command works:
find -name 'myfile.*' |& grep -v "Permission denied"
I don't understand why the ampersand needs to be put into this command, would have expected this to work but it doesn't.
find -name 'myfile.*' | grep -v "Permission denied"
Please explain the meaning of the ampersand.
bash command-line find grep
add a comment |
I am using cygwin to find a file on the cygdrive.
However I need to suppress the permission denied messages (otherwise the results get hidden in the error messages). The following command works:
find -name 'myfile.*' |& grep -v "Permission denied"
I don't understand why the ampersand needs to be put into this command, would have expected this to work but it doesn't.
find -name 'myfile.*' | grep -v "Permission denied"
Please explain the meaning of the ampersand.
bash command-line find grep
I am using cygwin to find a file on the cygdrive.
However I need to suppress the permission denied messages (otherwise the results get hidden in the error messages). The following command works:
find -name 'myfile.*' |& grep -v "Permission denied"
I don't understand why the ampersand needs to be put into this command, would have expected this to work but it doesn't.
find -name 'myfile.*' | grep -v "Permission denied"
Please explain the meaning of the ampersand.
bash command-line find grep
bash command-line find grep
edited 12 hours ago
Pablo Bianchi
2,81821534
2,81821534
asked Feb 5 '11 at 19:25
HKKHKK
198116
198116
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
In Unix-like systems, there are two output paths that if left unmodified will send output to your screen. Standard error (or stderr) is the one that captures most failures and error conditions.
To pass the permission denied message in the stderr to the same output stream as "regular output" you must combine the two. In your example, in order for your grep -v
to properly operate on it, you combine stdout (standard output) and stderr with the arcane syntax you see.
From GNU Bash manual section 3.2.2 Pipelines:
If ‘
|&
’ is used, command1’s standard error, in addition to its
standard output, is connected to command2’s standard input through
the pipe; it is shorthand for2>&1 |
. This implicit redirection of
the standard error to the standard output is performed after any
redirections specified by the command.
Also, as geirha points out, if you want to just get rid of stderr output, you would want to do something like
find -name 'myfile.*' 2> /dev/null
or perhaps
find -name 'myfile.*' 2> /tmp/errorlog
And note that if you have strings of commands, such as a find
passing its output to xargs
you would need to put the entire pipeline of commands in parentheses to capture the output from all components of the command. E.g.,
(find | egrep ^[RS].[0-9]+/.svg] | xargs head -1 ) 2> /dev/null
If you left out the parentheses, and did this instead --
find | egrep ^[RS].[0-9]+/.svg] | xargs head -1 2> /dev/null
you would still see permission denied errors from the find or egrep, but stderr would be redirected for xargs.
As you've seen, you would likely throw away the stderr only after viewing its contents during a test run.
Note that with GNU find
and as far as I can tell, any POSIX-compliant find
, the -print
option is implicit. You can still supply it explicitly if you like.
Seems to be only bash4+ wiki.bash-hackers.org/bash4#redirection
– Luke Exton
Mar 22 '16 at 9:08
1
@LukeExton Yes. In other shells,2>&1 |
may be used in place of|&
(i.e., one can explicitly redirect stderr to stdout and then pipe that to the next command in the pipeline).
– Eliah Kagan
Jan 10 '17 at 19:29
add a comment |
Error messages are written to stderr, not stdout, but |
pipes only stdout.
You probably want |&
, which pipes stderr as well as stdout.
add a comment |
If you want to ignore the error messages, just redirect stderr to /dev/null.
find . -name 'myfile.*' -print 2>/dev/null
Also, consider reading http://mywiki.wooledge.org/UsingFind.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f24953%2fusing-grep-with-pipe-and-ampersand-to-filter-errors-from-find%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
In Unix-like systems, there are two output paths that if left unmodified will send output to your screen. Standard error (or stderr) is the one that captures most failures and error conditions.
To pass the permission denied message in the stderr to the same output stream as "regular output" you must combine the two. In your example, in order for your grep -v
to properly operate on it, you combine stdout (standard output) and stderr with the arcane syntax you see.
From GNU Bash manual section 3.2.2 Pipelines:
If ‘
|&
’ is used, command1’s standard error, in addition to its
standard output, is connected to command2’s standard input through
the pipe; it is shorthand for2>&1 |
. This implicit redirection of
the standard error to the standard output is performed after any
redirections specified by the command.
Also, as geirha points out, if you want to just get rid of stderr output, you would want to do something like
find -name 'myfile.*' 2> /dev/null
or perhaps
find -name 'myfile.*' 2> /tmp/errorlog
And note that if you have strings of commands, such as a find
passing its output to xargs
you would need to put the entire pipeline of commands in parentheses to capture the output from all components of the command. E.g.,
(find | egrep ^[RS].[0-9]+/.svg] | xargs head -1 ) 2> /dev/null
If you left out the parentheses, and did this instead --
find | egrep ^[RS].[0-9]+/.svg] | xargs head -1 2> /dev/null
you would still see permission denied errors from the find or egrep, but stderr would be redirected for xargs.
As you've seen, you would likely throw away the stderr only after viewing its contents during a test run.
Note that with GNU find
and as far as I can tell, any POSIX-compliant find
, the -print
option is implicit. You can still supply it explicitly if you like.
Seems to be only bash4+ wiki.bash-hackers.org/bash4#redirection
– Luke Exton
Mar 22 '16 at 9:08
1
@LukeExton Yes. In other shells,2>&1 |
may be used in place of|&
(i.e., one can explicitly redirect stderr to stdout and then pipe that to the next command in the pipeline).
– Eliah Kagan
Jan 10 '17 at 19:29
add a comment |
In Unix-like systems, there are two output paths that if left unmodified will send output to your screen. Standard error (or stderr) is the one that captures most failures and error conditions.
To pass the permission denied message in the stderr to the same output stream as "regular output" you must combine the two. In your example, in order for your grep -v
to properly operate on it, you combine stdout (standard output) and stderr with the arcane syntax you see.
From GNU Bash manual section 3.2.2 Pipelines:
If ‘
|&
’ is used, command1’s standard error, in addition to its
standard output, is connected to command2’s standard input through
the pipe; it is shorthand for2>&1 |
. This implicit redirection of
the standard error to the standard output is performed after any
redirections specified by the command.
Also, as geirha points out, if you want to just get rid of stderr output, you would want to do something like
find -name 'myfile.*' 2> /dev/null
or perhaps
find -name 'myfile.*' 2> /tmp/errorlog
And note that if you have strings of commands, such as a find
passing its output to xargs
you would need to put the entire pipeline of commands in parentheses to capture the output from all components of the command. E.g.,
(find | egrep ^[RS].[0-9]+/.svg] | xargs head -1 ) 2> /dev/null
If you left out the parentheses, and did this instead --
find | egrep ^[RS].[0-9]+/.svg] | xargs head -1 2> /dev/null
you would still see permission denied errors from the find or egrep, but stderr would be redirected for xargs.
As you've seen, you would likely throw away the stderr only after viewing its contents during a test run.
Note that with GNU find
and as far as I can tell, any POSIX-compliant find
, the -print
option is implicit. You can still supply it explicitly if you like.
Seems to be only bash4+ wiki.bash-hackers.org/bash4#redirection
– Luke Exton
Mar 22 '16 at 9:08
1
@LukeExton Yes. In other shells,2>&1 |
may be used in place of|&
(i.e., one can explicitly redirect stderr to stdout and then pipe that to the next command in the pipeline).
– Eliah Kagan
Jan 10 '17 at 19:29
add a comment |
In Unix-like systems, there are two output paths that if left unmodified will send output to your screen. Standard error (or stderr) is the one that captures most failures and error conditions.
To pass the permission denied message in the stderr to the same output stream as "regular output" you must combine the two. In your example, in order for your grep -v
to properly operate on it, you combine stdout (standard output) and stderr with the arcane syntax you see.
From GNU Bash manual section 3.2.2 Pipelines:
If ‘
|&
’ is used, command1’s standard error, in addition to its
standard output, is connected to command2’s standard input through
the pipe; it is shorthand for2>&1 |
. This implicit redirection of
the standard error to the standard output is performed after any
redirections specified by the command.
Also, as geirha points out, if you want to just get rid of stderr output, you would want to do something like
find -name 'myfile.*' 2> /dev/null
or perhaps
find -name 'myfile.*' 2> /tmp/errorlog
And note that if you have strings of commands, such as a find
passing its output to xargs
you would need to put the entire pipeline of commands in parentheses to capture the output from all components of the command. E.g.,
(find | egrep ^[RS].[0-9]+/.svg] | xargs head -1 ) 2> /dev/null
If you left out the parentheses, and did this instead --
find | egrep ^[RS].[0-9]+/.svg] | xargs head -1 2> /dev/null
you would still see permission denied errors from the find or egrep, but stderr would be redirected for xargs.
As you've seen, you would likely throw away the stderr only after viewing its contents during a test run.
Note that with GNU find
and as far as I can tell, any POSIX-compliant find
, the -print
option is implicit. You can still supply it explicitly if you like.
In Unix-like systems, there are two output paths that if left unmodified will send output to your screen. Standard error (or stderr) is the one that captures most failures and error conditions.
To pass the permission denied message in the stderr to the same output stream as "regular output" you must combine the two. In your example, in order for your grep -v
to properly operate on it, you combine stdout (standard output) and stderr with the arcane syntax you see.
From GNU Bash manual section 3.2.2 Pipelines:
If ‘
|&
’ is used, command1’s standard error, in addition to its
standard output, is connected to command2’s standard input through
the pipe; it is shorthand for2>&1 |
. This implicit redirection of
the standard error to the standard output is performed after any
redirections specified by the command.
Also, as geirha points out, if you want to just get rid of stderr output, you would want to do something like
find -name 'myfile.*' 2> /dev/null
or perhaps
find -name 'myfile.*' 2> /tmp/errorlog
And note that if you have strings of commands, such as a find
passing its output to xargs
you would need to put the entire pipeline of commands in parentheses to capture the output from all components of the command. E.g.,
(find | egrep ^[RS].[0-9]+/.svg] | xargs head -1 ) 2> /dev/null
If you left out the parentheses, and did this instead --
find | egrep ^[RS].[0-9]+/.svg] | xargs head -1 2> /dev/null
you would still see permission denied errors from the find or egrep, but stderr would be redirected for xargs.
As you've seen, you would likely throw away the stderr only after viewing its contents during a test run.
Note that with GNU find
and as far as I can tell, any POSIX-compliant find
, the -print
option is implicit. You can still supply it explicitly if you like.
edited Jan 10 '17 at 20:00
Luke Exton
1187
1187
answered Feb 5 '11 at 19:34
belacquabelacqua
15.9k1473103
15.9k1473103
Seems to be only bash4+ wiki.bash-hackers.org/bash4#redirection
– Luke Exton
Mar 22 '16 at 9:08
1
@LukeExton Yes. In other shells,2>&1 |
may be used in place of|&
(i.e., one can explicitly redirect stderr to stdout and then pipe that to the next command in the pipeline).
– Eliah Kagan
Jan 10 '17 at 19:29
add a comment |
Seems to be only bash4+ wiki.bash-hackers.org/bash4#redirection
– Luke Exton
Mar 22 '16 at 9:08
1
@LukeExton Yes. In other shells,2>&1 |
may be used in place of|&
(i.e., one can explicitly redirect stderr to stdout and then pipe that to the next command in the pipeline).
– Eliah Kagan
Jan 10 '17 at 19:29
Seems to be only bash4+ wiki.bash-hackers.org/bash4#redirection
– Luke Exton
Mar 22 '16 at 9:08
Seems to be only bash4+ wiki.bash-hackers.org/bash4#redirection
– Luke Exton
Mar 22 '16 at 9:08
1
1
@LukeExton Yes. In other shells,
2>&1 |
may be used in place of |&
(i.e., one can explicitly redirect stderr to stdout and then pipe that to the next command in the pipeline).– Eliah Kagan
Jan 10 '17 at 19:29
@LukeExton Yes. In other shells,
2>&1 |
may be used in place of |&
(i.e., one can explicitly redirect stderr to stdout and then pipe that to the next command in the pipeline).– Eliah Kagan
Jan 10 '17 at 19:29
add a comment |
Error messages are written to stderr, not stdout, but |
pipes only stdout.
You probably want |&
, which pipes stderr as well as stdout.
add a comment |
Error messages are written to stderr, not stdout, but |
pipes only stdout.
You probably want |&
, which pipes stderr as well as stdout.
add a comment |
Error messages are written to stderr, not stdout, but |
pipes only stdout.
You probably want |&
, which pipes stderr as well as stdout.
Error messages are written to stderr, not stdout, but |
pipes only stdout.
You probably want |&
, which pipes stderr as well as stdout.
edited Jan 10 '17 at 19:20
Eliah Kagan
82.5k22227369
82.5k22227369
answered Feb 5 '11 at 19:37
Florian DieschFlorian Diesch
65.4k16164181
65.4k16164181
add a comment |
add a comment |
If you want to ignore the error messages, just redirect stderr to /dev/null.
find . -name 'myfile.*' -print 2>/dev/null
Also, consider reading http://mywiki.wooledge.org/UsingFind.
add a comment |
If you want to ignore the error messages, just redirect stderr to /dev/null.
find . -name 'myfile.*' -print 2>/dev/null
Also, consider reading http://mywiki.wooledge.org/UsingFind.
add a comment |
If you want to ignore the error messages, just redirect stderr to /dev/null.
find . -name 'myfile.*' -print 2>/dev/null
Also, consider reading http://mywiki.wooledge.org/UsingFind.
If you want to ignore the error messages, just redirect stderr to /dev/null.
find . -name 'myfile.*' -print 2>/dev/null
Also, consider reading http://mywiki.wooledge.org/UsingFind.
answered Feb 6 '11 at 2:38
geirhageirha
31.2k95760
31.2k95760
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f24953%2fusing-grep-with-pipe-and-ampersand-to-filter-errors-from-find%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown