grep --exclude option doesn't always skip named pipes
I have a directory that contains, among other files, 3 named pipes: FIFO, FIFO1, and FIFO11. If I try something like
grep mypattern *
in this directory, grep hangs forever on the named pipes, so I need to exclude them. Unexpectedly,
grep --exclude='FIF*' mypattern *
does not solve the problem; grep still hangs forever. However,
grep -r --exclude='FIF*' mypattern .
does solve the hanging problem (albeit with the undesired side effect of searching all the subdirectories).
I did some testing that shows that grep --exclude ='FIF*' mypattern *
works as expected if FIFO etc. are regular files, not named pipes.
Questions:
- Why does
grep
skip--excludes
in both cases if they're regular files, and skips--excluded
named pipes in the recursive case, but doesn't skip named pipes in the non-recursive case? - Is there another way to format the exclusion that will skip these files in all cases?
- is there a better way to accomplish what I'm after? (EDIT: I just discovered the
--devices=skip
flag in grep, so that's the answer to this part ... but I'm still curious about the first two parts of the question)
grep fifo
add a comment |
I have a directory that contains, among other files, 3 named pipes: FIFO, FIFO1, and FIFO11. If I try something like
grep mypattern *
in this directory, grep hangs forever on the named pipes, so I need to exclude them. Unexpectedly,
grep --exclude='FIF*' mypattern *
does not solve the problem; grep still hangs forever. However,
grep -r --exclude='FIF*' mypattern .
does solve the hanging problem (albeit with the undesired side effect of searching all the subdirectories).
I did some testing that shows that grep --exclude ='FIF*' mypattern *
works as expected if FIFO etc. are regular files, not named pipes.
Questions:
- Why does
grep
skip--excludes
in both cases if they're regular files, and skips--excluded
named pipes in the recursive case, but doesn't skip named pipes in the non-recursive case? - Is there another way to format the exclusion that will skip these files in all cases?
- is there a better way to accomplish what I'm after? (EDIT: I just discovered the
--devices=skip
flag in grep, so that's the answer to this part ... but I'm still curious about the first two parts of the question)
grep fifo
I have no idea, however I would usefind . -type f -print0 | xargs -0 grep pattern
, to only search regular files.
– ctrl-alt-delor
Feb 7 at 11:55
If you have an answer, then put it is the answer section.
– ctrl-alt-delor
Feb 7 at 11:57
add a comment |
I have a directory that contains, among other files, 3 named pipes: FIFO, FIFO1, and FIFO11. If I try something like
grep mypattern *
in this directory, grep hangs forever on the named pipes, so I need to exclude them. Unexpectedly,
grep --exclude='FIF*' mypattern *
does not solve the problem; grep still hangs forever. However,
grep -r --exclude='FIF*' mypattern .
does solve the hanging problem (albeit with the undesired side effect of searching all the subdirectories).
I did some testing that shows that grep --exclude ='FIF*' mypattern *
works as expected if FIFO etc. are regular files, not named pipes.
Questions:
- Why does
grep
skip--excludes
in both cases if they're regular files, and skips--excluded
named pipes in the recursive case, but doesn't skip named pipes in the non-recursive case? - Is there another way to format the exclusion that will skip these files in all cases?
- is there a better way to accomplish what I'm after? (EDIT: I just discovered the
--devices=skip
flag in grep, so that's the answer to this part ... but I'm still curious about the first two parts of the question)
grep fifo
I have a directory that contains, among other files, 3 named pipes: FIFO, FIFO1, and FIFO11. If I try something like
grep mypattern *
in this directory, grep hangs forever on the named pipes, so I need to exclude them. Unexpectedly,
grep --exclude='FIF*' mypattern *
does not solve the problem; grep still hangs forever. However,
grep -r --exclude='FIF*' mypattern .
does solve the hanging problem (albeit with the undesired side effect of searching all the subdirectories).
I did some testing that shows that grep --exclude ='FIF*' mypattern *
works as expected if FIFO etc. are regular files, not named pipes.
Questions:
- Why does
grep
skip--excludes
in both cases if they're regular files, and skips--excluded
named pipes in the recursive case, but doesn't skip named pipes in the non-recursive case? - Is there another way to format the exclusion that will skip these files in all cases?
- is there a better way to accomplish what I'm after? (EDIT: I just discovered the
--devices=skip
flag in grep, so that's the answer to this part ... but I'm still curious about the first two parts of the question)
grep fifo
grep fifo
edited Feb 7 at 8:22
Community♦
1
1
asked Feb 7 at 7:24
rasras
284
284
I have no idea, however I would usefind . -type f -print0 | xargs -0 grep pattern
, to only search regular files.
– ctrl-alt-delor
Feb 7 at 11:55
If you have an answer, then put it is the answer section.
– ctrl-alt-delor
Feb 7 at 11:57
add a comment |
I have no idea, however I would usefind . -type f -print0 | xargs -0 grep pattern
, to only search regular files.
– ctrl-alt-delor
Feb 7 at 11:55
If you have an answer, then put it is the answer section.
– ctrl-alt-delor
Feb 7 at 11:57
I have no idea, however I would use
find . -type f -print0 | xargs -0 grep pattern
, to only search regular files.– ctrl-alt-delor
Feb 7 at 11:55
I have no idea, however I would use
find . -type f -print0 | xargs -0 grep pattern
, to only search regular files.– ctrl-alt-delor
Feb 7 at 11:55
If you have an answer, then put it is the answer section.
– ctrl-alt-delor
Feb 7 at 11:57
If you have an answer, then put it is the answer section.
– ctrl-alt-delor
Feb 7 at 11:57
add a comment |
2 Answers
2
active
oldest
votes
It seems grep
still opens files even if the regex tells it to skip them:
$ ll
total 4.0K
p-w--w---- 1 user user 0 Feb 7 16:44 pip-fifo
--w--w---- 1 user user 4 Feb 7 16:44 pip-file
lrwxrwxrwx 1 user user 4 Feb 7 16:44 pip-link -> file
(Note: none of these have read permissions.)
$ strace -e openat grep foo --exclude='pip*' pip-file pip-link pip-fifo
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
grep: pip-file: Permission denied
openat(AT_FDCWD, "pip-link", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
grep: pip-link: No such file or directory
openat(AT_FDCWD, "pip-fifo", O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
grep: pip-fifo: Permission denied
+++ exited with 2 +++
Granting read permissions, it appears that it doesn't try to read them after opening if they are excluded:
$ strace -e openat grep foo --exclude='pip*' pip-file pip-link pip-fifo
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
openat(AT_FDCWD, "pip-link", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
grep: pip-link: No such file or directory
openat(AT_FDCWD, "pip-fifo", O_RDONLY|O_NOCTTY^Cstrace: Process 31058 detached
<detached ...>
$ strace -e openat,read grep foo --exclude='pip*' pip-file
read(3, "177ELF2113>100025"..., 832) = 832
read(3, "177ELF2113>1240r"..., 832) = 832
read(3, "177ELF21133>1Pt2"..., 832) = 832
read(3, "177ELF2113>1260`"..., 832) = 832
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
+++ exited with 1 +++
$ strace -e openat,read grep foo --exclude='pipe*' pip-file
read(3, "177ELF2113>100025"..., 832) = 832
read(3, "177ELF2113>1240r"..., 832) = 832
read(3, "177ELF21133>1Pt2"..., 832) = 832
read(3, "177ELF2113>1260`"..., 832) = 832
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
read(3, "foon", 32768) = 4
foo
read(3, "", 32768) = 0
+++ exited with 0 +++
And since openat
wasn't called with O_NONBLOCK
, the opening itself hangs, and grep doesn't reach the part where it excludes it from reading.
Looking at the source code, I believe the flow is like this:
- If not recursive, call
grep_command_line_arg
on each file. - That calls
grepfile
if not on stdin.
grepfile
callsgrepdesc
after opening the file.
grepdesc
checks for excluding the file.
When recursive:
grepdirent
checks for excluding the file before callinggrepfile
, so the failingopenat
never happens.
Accepting this answer, as it describes the behavior and its cause exactly. For the sake of completeness, I will note that bothgrep --devices=skip mypattern *
and the various solutions involvingfind
solve the original problem. (I'll also note that thisgrep
behavior seems like a suboptimal implementation!)
– ras
Feb 7 at 18:50
add a comment |
why don't you combine with "find"? Get a list of nothing but files and grep into them:
find /path/to/dir -type f -exec grep pattern {} ;
Whilst the idea is good, the implementation is bad. I suggestfind /path/to/dir -type f -maxdepth 1 -exec grep pattern /dev/null {} +
- the maxdepth will limit it to the current directory. The change from;
to+
will make find run grep for a batch of files, rather than running one grep for each one. Adding the /dev/null removes the very small chance of a run with a single file, which causes grep to change the output format. See unix.stackexchange.com/questions/275637/… if you lack maxdepth.
– icarus
Feb 7 at 10:45
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f499229%2fgrep-exclude-option-doesnt-always-skip-named-pipes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It seems grep
still opens files even if the regex tells it to skip them:
$ ll
total 4.0K
p-w--w---- 1 user user 0 Feb 7 16:44 pip-fifo
--w--w---- 1 user user 4 Feb 7 16:44 pip-file
lrwxrwxrwx 1 user user 4 Feb 7 16:44 pip-link -> file
(Note: none of these have read permissions.)
$ strace -e openat grep foo --exclude='pip*' pip-file pip-link pip-fifo
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
grep: pip-file: Permission denied
openat(AT_FDCWD, "pip-link", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
grep: pip-link: No such file or directory
openat(AT_FDCWD, "pip-fifo", O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
grep: pip-fifo: Permission denied
+++ exited with 2 +++
Granting read permissions, it appears that it doesn't try to read them after opening if they are excluded:
$ strace -e openat grep foo --exclude='pip*' pip-file pip-link pip-fifo
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
openat(AT_FDCWD, "pip-link", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
grep: pip-link: No such file or directory
openat(AT_FDCWD, "pip-fifo", O_RDONLY|O_NOCTTY^Cstrace: Process 31058 detached
<detached ...>
$ strace -e openat,read grep foo --exclude='pip*' pip-file
read(3, "177ELF2113>100025"..., 832) = 832
read(3, "177ELF2113>1240r"..., 832) = 832
read(3, "177ELF21133>1Pt2"..., 832) = 832
read(3, "177ELF2113>1260`"..., 832) = 832
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
+++ exited with 1 +++
$ strace -e openat,read grep foo --exclude='pipe*' pip-file
read(3, "177ELF2113>100025"..., 832) = 832
read(3, "177ELF2113>1240r"..., 832) = 832
read(3, "177ELF21133>1Pt2"..., 832) = 832
read(3, "177ELF2113>1260`"..., 832) = 832
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
read(3, "foon", 32768) = 4
foo
read(3, "", 32768) = 0
+++ exited with 0 +++
And since openat
wasn't called with O_NONBLOCK
, the opening itself hangs, and grep doesn't reach the part where it excludes it from reading.
Looking at the source code, I believe the flow is like this:
- If not recursive, call
grep_command_line_arg
on each file. - That calls
grepfile
if not on stdin.
grepfile
callsgrepdesc
after opening the file.
grepdesc
checks for excluding the file.
When recursive:
grepdirent
checks for excluding the file before callinggrepfile
, so the failingopenat
never happens.
Accepting this answer, as it describes the behavior and its cause exactly. For the sake of completeness, I will note that bothgrep --devices=skip mypattern *
and the various solutions involvingfind
solve the original problem. (I'll also note that thisgrep
behavior seems like a suboptimal implementation!)
– ras
Feb 7 at 18:50
add a comment |
It seems grep
still opens files even if the regex tells it to skip them:
$ ll
total 4.0K
p-w--w---- 1 user user 0 Feb 7 16:44 pip-fifo
--w--w---- 1 user user 4 Feb 7 16:44 pip-file
lrwxrwxrwx 1 user user 4 Feb 7 16:44 pip-link -> file
(Note: none of these have read permissions.)
$ strace -e openat grep foo --exclude='pip*' pip-file pip-link pip-fifo
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
grep: pip-file: Permission denied
openat(AT_FDCWD, "pip-link", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
grep: pip-link: No such file or directory
openat(AT_FDCWD, "pip-fifo", O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
grep: pip-fifo: Permission denied
+++ exited with 2 +++
Granting read permissions, it appears that it doesn't try to read them after opening if they are excluded:
$ strace -e openat grep foo --exclude='pip*' pip-file pip-link pip-fifo
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
openat(AT_FDCWD, "pip-link", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
grep: pip-link: No such file or directory
openat(AT_FDCWD, "pip-fifo", O_RDONLY|O_NOCTTY^Cstrace: Process 31058 detached
<detached ...>
$ strace -e openat,read grep foo --exclude='pip*' pip-file
read(3, "177ELF2113>100025"..., 832) = 832
read(3, "177ELF2113>1240r"..., 832) = 832
read(3, "177ELF21133>1Pt2"..., 832) = 832
read(3, "177ELF2113>1260`"..., 832) = 832
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
+++ exited with 1 +++
$ strace -e openat,read grep foo --exclude='pipe*' pip-file
read(3, "177ELF2113>100025"..., 832) = 832
read(3, "177ELF2113>1240r"..., 832) = 832
read(3, "177ELF21133>1Pt2"..., 832) = 832
read(3, "177ELF2113>1260`"..., 832) = 832
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
read(3, "foon", 32768) = 4
foo
read(3, "", 32768) = 0
+++ exited with 0 +++
And since openat
wasn't called with O_NONBLOCK
, the opening itself hangs, and grep doesn't reach the part where it excludes it from reading.
Looking at the source code, I believe the flow is like this:
- If not recursive, call
grep_command_line_arg
on each file. - That calls
grepfile
if not on stdin.
grepfile
callsgrepdesc
after opening the file.
grepdesc
checks for excluding the file.
When recursive:
grepdirent
checks for excluding the file before callinggrepfile
, so the failingopenat
never happens.
Accepting this answer, as it describes the behavior and its cause exactly. For the sake of completeness, I will note that bothgrep --devices=skip mypattern *
and the various solutions involvingfind
solve the original problem. (I'll also note that thisgrep
behavior seems like a suboptimal implementation!)
– ras
Feb 7 at 18:50
add a comment |
It seems grep
still opens files even if the regex tells it to skip them:
$ ll
total 4.0K
p-w--w---- 1 user user 0 Feb 7 16:44 pip-fifo
--w--w---- 1 user user 4 Feb 7 16:44 pip-file
lrwxrwxrwx 1 user user 4 Feb 7 16:44 pip-link -> file
(Note: none of these have read permissions.)
$ strace -e openat grep foo --exclude='pip*' pip-file pip-link pip-fifo
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
grep: pip-file: Permission denied
openat(AT_FDCWD, "pip-link", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
grep: pip-link: No such file or directory
openat(AT_FDCWD, "pip-fifo", O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
grep: pip-fifo: Permission denied
+++ exited with 2 +++
Granting read permissions, it appears that it doesn't try to read them after opening if they are excluded:
$ strace -e openat grep foo --exclude='pip*' pip-file pip-link pip-fifo
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
openat(AT_FDCWD, "pip-link", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
grep: pip-link: No such file or directory
openat(AT_FDCWD, "pip-fifo", O_RDONLY|O_NOCTTY^Cstrace: Process 31058 detached
<detached ...>
$ strace -e openat,read grep foo --exclude='pip*' pip-file
read(3, "177ELF2113>100025"..., 832) = 832
read(3, "177ELF2113>1240r"..., 832) = 832
read(3, "177ELF21133>1Pt2"..., 832) = 832
read(3, "177ELF2113>1260`"..., 832) = 832
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
+++ exited with 1 +++
$ strace -e openat,read grep foo --exclude='pipe*' pip-file
read(3, "177ELF2113>100025"..., 832) = 832
read(3, "177ELF2113>1240r"..., 832) = 832
read(3, "177ELF21133>1Pt2"..., 832) = 832
read(3, "177ELF2113>1260`"..., 832) = 832
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
read(3, "foon", 32768) = 4
foo
read(3, "", 32768) = 0
+++ exited with 0 +++
And since openat
wasn't called with O_NONBLOCK
, the opening itself hangs, and grep doesn't reach the part where it excludes it from reading.
Looking at the source code, I believe the flow is like this:
- If not recursive, call
grep_command_line_arg
on each file. - That calls
grepfile
if not on stdin.
grepfile
callsgrepdesc
after opening the file.
grepdesc
checks for excluding the file.
When recursive:
grepdirent
checks for excluding the file before callinggrepfile
, so the failingopenat
never happens.
It seems grep
still opens files even if the regex tells it to skip them:
$ ll
total 4.0K
p-w--w---- 1 user user 0 Feb 7 16:44 pip-fifo
--w--w---- 1 user user 4 Feb 7 16:44 pip-file
lrwxrwxrwx 1 user user 4 Feb 7 16:44 pip-link -> file
(Note: none of these have read permissions.)
$ strace -e openat grep foo --exclude='pip*' pip-file pip-link pip-fifo
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
grep: pip-file: Permission denied
openat(AT_FDCWD, "pip-link", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
grep: pip-link: No such file or directory
openat(AT_FDCWD, "pip-fifo", O_RDONLY|O_NOCTTY) = -1 EACCES (Permission denied)
grep: pip-fifo: Permission denied
+++ exited with 2 +++
Granting read permissions, it appears that it doesn't try to read them after opening if they are excluded:
$ strace -e openat grep foo --exclude='pip*' pip-file pip-link pip-fifo
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
openat(AT_FDCWD, "pip-link", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
grep: pip-link: No such file or directory
openat(AT_FDCWD, "pip-fifo", O_RDONLY|O_NOCTTY^Cstrace: Process 31058 detached
<detached ...>
$ strace -e openat,read grep foo --exclude='pip*' pip-file
read(3, "177ELF2113>100025"..., 832) = 832
read(3, "177ELF2113>1240r"..., 832) = 832
read(3, "177ELF21133>1Pt2"..., 832) = 832
read(3, "177ELF2113>1260`"..., 832) = 832
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
+++ exited with 1 +++
$ strace -e openat,read grep foo --exclude='pipe*' pip-file
read(3, "177ELF2113>100025"..., 832) = 832
read(3, "177ELF2113>1240r"..., 832) = 832
read(3, "177ELF21133>1Pt2"..., 832) = 832
read(3, "177ELF2113>1260`"..., 832) = 832
openat(AT_FDCWD, "pip-file", O_RDONLY|O_NOCTTY) = 3
read(3, "foon", 32768) = 4
foo
read(3, "", 32768) = 0
+++ exited with 0 +++
And since openat
wasn't called with O_NONBLOCK
, the opening itself hangs, and grep doesn't reach the part where it excludes it from reading.
Looking at the source code, I believe the flow is like this:
- If not recursive, call
grep_command_line_arg
on each file. - That calls
grepfile
if not on stdin.
grepfile
callsgrepdesc
after opening the file.
grepdesc
checks for excluding the file.
When recursive:
grepdirent
checks for excluding the file before callinggrepfile
, so the failingopenat
never happens.
answered Feb 7 at 8:23
greppy mcgrepfacegreppy mcgrepface
861
861
Accepting this answer, as it describes the behavior and its cause exactly. For the sake of completeness, I will note that bothgrep --devices=skip mypattern *
and the various solutions involvingfind
solve the original problem. (I'll also note that thisgrep
behavior seems like a suboptimal implementation!)
– ras
Feb 7 at 18:50
add a comment |
Accepting this answer, as it describes the behavior and its cause exactly. For the sake of completeness, I will note that bothgrep --devices=skip mypattern *
and the various solutions involvingfind
solve the original problem. (I'll also note that thisgrep
behavior seems like a suboptimal implementation!)
– ras
Feb 7 at 18:50
Accepting this answer, as it describes the behavior and its cause exactly. For the sake of completeness, I will note that both
grep --devices=skip mypattern *
and the various solutions involving find
solve the original problem. (I'll also note that this grep
behavior seems like a suboptimal implementation!)– ras
Feb 7 at 18:50
Accepting this answer, as it describes the behavior and its cause exactly. For the sake of completeness, I will note that both
grep --devices=skip mypattern *
and the various solutions involving find
solve the original problem. (I'll also note that this grep
behavior seems like a suboptimal implementation!)– ras
Feb 7 at 18:50
add a comment |
why don't you combine with "find"? Get a list of nothing but files and grep into them:
find /path/to/dir -type f -exec grep pattern {} ;
Whilst the idea is good, the implementation is bad. I suggestfind /path/to/dir -type f -maxdepth 1 -exec grep pattern /dev/null {} +
- the maxdepth will limit it to the current directory. The change from;
to+
will make find run grep for a batch of files, rather than running one grep for each one. Adding the /dev/null removes the very small chance of a run with a single file, which causes grep to change the output format. See unix.stackexchange.com/questions/275637/… if you lack maxdepth.
– icarus
Feb 7 at 10:45
add a comment |
why don't you combine with "find"? Get a list of nothing but files and grep into them:
find /path/to/dir -type f -exec grep pattern {} ;
Whilst the idea is good, the implementation is bad. I suggestfind /path/to/dir -type f -maxdepth 1 -exec grep pattern /dev/null {} +
- the maxdepth will limit it to the current directory. The change from;
to+
will make find run grep for a batch of files, rather than running one grep for each one. Adding the /dev/null removes the very small chance of a run with a single file, which causes grep to change the output format. See unix.stackexchange.com/questions/275637/… if you lack maxdepth.
– icarus
Feb 7 at 10:45
add a comment |
why don't you combine with "find"? Get a list of nothing but files and grep into them:
find /path/to/dir -type f -exec grep pattern {} ;
why don't you combine with "find"? Get a list of nothing but files and grep into them:
find /path/to/dir -type f -exec grep pattern {} ;
answered Feb 7 at 8:47
George IvanovGeorge Ivanov
32826
32826
Whilst the idea is good, the implementation is bad. I suggestfind /path/to/dir -type f -maxdepth 1 -exec grep pattern /dev/null {} +
- the maxdepth will limit it to the current directory. The change from;
to+
will make find run grep for a batch of files, rather than running one grep for each one. Adding the /dev/null removes the very small chance of a run with a single file, which causes grep to change the output format. See unix.stackexchange.com/questions/275637/… if you lack maxdepth.
– icarus
Feb 7 at 10:45
add a comment |
Whilst the idea is good, the implementation is bad. I suggestfind /path/to/dir -type f -maxdepth 1 -exec grep pattern /dev/null {} +
- the maxdepth will limit it to the current directory. The change from;
to+
will make find run grep for a batch of files, rather than running one grep for each one. Adding the /dev/null removes the very small chance of a run with a single file, which causes grep to change the output format. See unix.stackexchange.com/questions/275637/… if you lack maxdepth.
– icarus
Feb 7 at 10:45
Whilst the idea is good, the implementation is bad. I suggest
find /path/to/dir -type f -maxdepth 1 -exec grep pattern /dev/null {} +
- the maxdepth will limit it to the current directory. The change from ;
to +
will make find run grep for a batch of files, rather than running one grep for each one. Adding the /dev/null removes the very small chance of a run with a single file, which causes grep to change the output format. See unix.stackexchange.com/questions/275637/… if you lack maxdepth.– icarus
Feb 7 at 10:45
Whilst the idea is good, the implementation is bad. I suggest
find /path/to/dir -type f -maxdepth 1 -exec grep pattern /dev/null {} +
- the maxdepth will limit it to the current directory. The change from ;
to +
will make find run grep for a batch of files, rather than running one grep for each one. Adding the /dev/null removes the very small chance of a run with a single file, which causes grep to change the output format. See unix.stackexchange.com/questions/275637/… if you lack maxdepth.– icarus
Feb 7 at 10:45
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f499229%2fgrep-exclude-option-doesnt-always-skip-named-pipes%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
I have no idea, however I would use
find . -type f -print0 | xargs -0 grep pattern
, to only search regular files.– ctrl-alt-delor
Feb 7 at 11:55
If you have an answer, then put it is the answer section.
– ctrl-alt-delor
Feb 7 at 11:57