grep --exclude option doesn't always skip named pipes












5















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:




  1. 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?

  2. Is there another way to format the exclusion that will skip these files in all cases?

  3. 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)










share|improve this question

























  • 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
















5















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:




  1. 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?

  2. Is there another way to format the exclusion that will skip these files in all cases?

  3. 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)










share|improve this question

























  • 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














5












5








5








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:




  1. 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?

  2. Is there another way to format the exclusion that will skip these files in all cases?

  3. 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)










share|improve this question
















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:




  1. 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?

  2. Is there another way to format the exclusion that will skip these files in all cases?

  3. 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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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



















  • 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

















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










2 Answers
2






active

oldest

votes


















7














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:




  1. If not recursive, call grep_command_line_arg on each file.

  2. That calls grepfile if not on stdin.


  3. grepfile calls grepdesc after opening the file.


  4. grepdesc checks for excluding the file.


When recursive:





  1. grepdirent checks for excluding the file before calling grepfile, so the failing openat never happens.






share|improve this answer
























  • 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





















1














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 {} ;





share|improve this answer
























  • 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












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
});


}
});














draft saved

draft discarded


















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









7














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:




  1. If not recursive, call grep_command_line_arg on each file.

  2. That calls grepfile if not on stdin.


  3. grepfile calls grepdesc after opening the file.


  4. grepdesc checks for excluding the file.


When recursive:





  1. grepdirent checks for excluding the file before calling grepfile, so the failing openat never happens.






share|improve this answer
























  • 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


















7














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:




  1. If not recursive, call grep_command_line_arg on each file.

  2. That calls grepfile if not on stdin.


  3. grepfile calls grepdesc after opening the file.


  4. grepdesc checks for excluding the file.


When recursive:





  1. grepdirent checks for excluding the file before calling grepfile, so the failing openat never happens.






share|improve this answer
























  • 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
















7












7








7







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:




  1. If not recursive, call grep_command_line_arg on each file.

  2. That calls grepfile if not on stdin.


  3. grepfile calls grepdesc after opening the file.


  4. grepdesc checks for excluding the file.


When recursive:





  1. grepdirent checks for excluding the file before calling grepfile, so the failing openat never happens.






share|improve this answer













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:




  1. If not recursive, call grep_command_line_arg on each file.

  2. That calls grepfile if not on stdin.


  3. grepfile calls grepdesc after opening the file.


  4. grepdesc checks for excluding the file.


When recursive:





  1. grepdirent checks for excluding the file before calling grepfile, so the failing openat never happens.







share|improve this answer












share|improve this answer



share|improve this answer










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 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



















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















1














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 {} ;





share|improve this answer
























  • 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
















1














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 {} ;





share|improve this answer
























  • 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














1












1








1







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 {} ;





share|improve this answer













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 {} ;






share|improve this answer












share|improve this answer



share|improve this answer










answered Feb 7 at 8:47









George IvanovGeorge Ivanov

32826




32826













  • 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

















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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Human spaceflight

Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

File:DeusFollowingSea.jpg