find: missing argument to -exec
Clash Royale CLAN TAG#URR8PPP
up vote
5
down vote
favorite
I'm trying to run the following command:
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
This is returning an error:
find: missing argument to -exec
I can't see what's wrong with this command, as it seems to match the man page:
-exec command +
This variant of the -exec option runs the specified command on
the selected files, but the command line is built by appending
each selected file name at the end; the total number of invoca-
tions of the command will be much less than the number of
matched files. The command line is built in much the same way
that xargs builds its command lines. Only one instance of ''
is allowed within the command. The command is executed in the
starting directory.
I also tried:
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar +
find a/folder b/folder -name *.c -o -name *.h -exec 'grep -I foobar' +
find a/folder b/folder -name *.c -o -name *.h -exec 'grep -I foobar' '' +
find a/folder b/folder -name "*.c" -o -name "*.h" -exec grep -I foobar '' +
find a/folder b/folder ( -name *.c -o -name *.h ) -exec grep -I foobar '' +
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
find
 |Â
show 1 more comment
up vote
5
down vote
favorite
I'm trying to run the following command:
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
This is returning an error:
find: missing argument to -exec
I can't see what's wrong with this command, as it seems to match the man page:
-exec command +
This variant of the -exec option runs the specified command on
the selected files, but the command line is built by appending
each selected file name at the end; the total number of invoca-
tions of the command will be much less than the number of
matched files. The command line is built in much the same way
that xargs builds its command lines. Only one instance of ''
is allowed within the command. The command is executed in the
starting directory.
I also tried:
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar +
find a/folder b/folder -name *.c -o -name *.h -exec 'grep -I foobar' +
find a/folder b/folder -name *.c -o -name *.h -exec 'grep -I foobar' '' +
find a/folder b/folder -name "*.c" -o -name "*.h" -exec grep -I foobar '' +
find a/folder b/folder ( -name *.c -o -name *.h ) -exec grep -I foobar '' +
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
find
Have you tried escaping the+
at the end?find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
â jayhendren
May 7 '14 at 21:37
Yes, no dice there either.
â David Kennedy
May 7 '14 at 21:39
1
You may be using an old version of GNUfind
. Though the-exec cmd +
variant is POSIX and has been available since the 80s, GNU find only added it (relatively) recently (2005). What doesfind --version
tell you?
â Stéphane Chazelas
May 7 '14 at 21:43
GNU find version 4.1 - it's the one that ships with git for Windows.
â David Kennedy
May 7 '14 at 21:44
2
@Koveras, that would be it then.-exec +
was added in 4.2.12 in 2005. In older GNU finds, you can use the (non-POSIX)-print0 | xargs -r0
to get something similar.4.1
is from 1994.
â Stéphane Chazelas
May 7 '14 at 21:47
 |Â
show 1 more comment
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I'm trying to run the following command:
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
This is returning an error:
find: missing argument to -exec
I can't see what's wrong with this command, as it seems to match the man page:
-exec command +
This variant of the -exec option runs the specified command on
the selected files, but the command line is built by appending
each selected file name at the end; the total number of invoca-
tions of the command will be much less than the number of
matched files. The command line is built in much the same way
that xargs builds its command lines. Only one instance of ''
is allowed within the command. The command is executed in the
starting directory.
I also tried:
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar +
find a/folder b/folder -name *.c -o -name *.h -exec 'grep -I foobar' +
find a/folder b/folder -name *.c -o -name *.h -exec 'grep -I foobar' '' +
find a/folder b/folder -name "*.c" -o -name "*.h" -exec grep -I foobar '' +
find a/folder b/folder ( -name *.c -o -name *.h ) -exec grep -I foobar '' +
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
find
I'm trying to run the following command:
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
This is returning an error:
find: missing argument to -exec
I can't see what's wrong with this command, as it seems to match the man page:
-exec command +
This variant of the -exec option runs the specified command on
the selected files, but the command line is built by appending
each selected file name at the end; the total number of invoca-
tions of the command will be much less than the number of
matched files. The command line is built in much the same way
that xargs builds its command lines. Only one instance of ''
is allowed within the command. The command is executed in the
starting directory.
I also tried:
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar +
find a/folder b/folder -name *.c -o -name *.h -exec 'grep -I foobar' +
find a/folder b/folder -name *.c -o -name *.h -exec 'grep -I foobar' '' +
find a/folder b/folder -name "*.c" -o -name "*.h" -exec grep -I foobar '' +
find a/folder b/folder ( -name *.c -o -name *.h ) -exec grep -I foobar '' +
find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
find
find
edited May 8 '14 at 3:40
Gilles
509k12010071537
509k12010071537
asked May 7 '14 at 21:10
David Kennedy
86571436
86571436
Have you tried escaping the+
at the end?find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
â jayhendren
May 7 '14 at 21:37
Yes, no dice there either.
â David Kennedy
May 7 '14 at 21:39
1
You may be using an old version of GNUfind
. Though the-exec cmd +
variant is POSIX and has been available since the 80s, GNU find only added it (relatively) recently (2005). What doesfind --version
tell you?
â Stéphane Chazelas
May 7 '14 at 21:43
GNU find version 4.1 - it's the one that ships with git for Windows.
â David Kennedy
May 7 '14 at 21:44
2
@Koveras, that would be it then.-exec +
was added in 4.2.12 in 2005. In older GNU finds, you can use the (non-POSIX)-print0 | xargs -r0
to get something similar.4.1
is from 1994.
â Stéphane Chazelas
May 7 '14 at 21:47
 |Â
show 1 more comment
Have you tried escaping the+
at the end?find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
â jayhendren
May 7 '14 at 21:37
Yes, no dice there either.
â David Kennedy
May 7 '14 at 21:39
1
You may be using an old version of GNUfind
. Though the-exec cmd +
variant is POSIX and has been available since the 80s, GNU find only added it (relatively) recently (2005). What doesfind --version
tell you?
â Stéphane Chazelas
May 7 '14 at 21:43
GNU find version 4.1 - it's the one that ships with git for Windows.
â David Kennedy
May 7 '14 at 21:44
2
@Koveras, that would be it then.-exec +
was added in 4.2.12 in 2005. In older GNU finds, you can use the (non-POSIX)-print0 | xargs -r0
to get something similar.4.1
is from 1994.
â Stéphane Chazelas
May 7 '14 at 21:47
Have you tried escaping the
+
at the end? find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
â jayhendren
May 7 '14 at 21:37
Have you tried escaping the
+
at the end? find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
â jayhendren
May 7 '14 at 21:37
Yes, no dice there either.
â David Kennedy
May 7 '14 at 21:39
Yes, no dice there either.
â David Kennedy
May 7 '14 at 21:39
1
1
You may be using an old version of GNU
find
. Though the -exec cmd +
variant is POSIX and has been available since the 80s, GNU find only added it (relatively) recently (2005). What does find --version
tell you?â Stéphane Chazelas
May 7 '14 at 21:43
You may be using an old version of GNU
find
. Though the -exec cmd +
variant is POSIX and has been available since the 80s, GNU find only added it (relatively) recently (2005). What does find --version
tell you?â Stéphane Chazelas
May 7 '14 at 21:43
GNU find version 4.1 - it's the one that ships with git for Windows.
â David Kennedy
May 7 '14 at 21:44
GNU find version 4.1 - it's the one that ships with git for Windows.
â David Kennedy
May 7 '14 at 21:44
2
2
@Koveras, that would be it then.
-exec +
was added in 4.2.12 in 2005. In older GNU finds, you can use the (non-POSIX) -print0 | xargs -r0
to get something similar. 4.1
is from 1994.â Stéphane Chazelas
May 7 '14 at 21:47
@Koveras, that would be it then.
-exec +
was added in 4.2.12 in 2005. In older GNU finds, you can use the (non-POSIX) -print0 | xargs -r0
to get something similar. 4.1
is from 1994.â Stéphane Chazelas
May 7 '14 at 21:47
 |Â
show 1 more comment
4 Answers
4
active
oldest
votes
up vote
7
down vote
accepted
You need to remove the backticks you use around . The command can be simplified like this:
find a/folder b/folder -name "*.[ch]" -exec grep -I foobar +
Should you use an archaic GNU find version, this should still work:
find a/folder b/folder -name "*.[ch]" -exec grep -I foobar ;
Oops, they were meant to be quotes not backticks.
â David Kennedy
May 7 '14 at 21:21
Quotes would be useless ashas no specific meaning to the shell.
â jlliagre
May 7 '14 at 21:26
From find man pages: "The string '' is replaced by the current file name being processed everywhere it occurs in the arguments to the command, not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped (with a '') or quoted to protect them from expansion by the shell."
â David Kennedy
May 7 '14 at 21:29
1
I indeed read that in the manual page but the fact is there is no shell I'm aware of that requires quoting the curly braces. What shell are you using ?
â jlliagre
May 7 '14 at 21:37
bash. With or without the quotes I get the error anyways.
â David Kennedy
May 7 '14 at 21:38
 |Â
show 4 more comments
up vote
3
down vote
âÂÂmissing argument to -exec
â usually means that the argument to -exec
is missing its terminator. The terminator must either be an argument containing just the character ;
(which needs to be quoted in a shell command, so it's typically written ;
or ';'
), or two successive arguments containing and
+
.
Stephane Chazelas has identified that you're using an older version of GNU find which doesn't support -exec ⦠+
, only -exec ;
. Although GNU was a late adopter of -exec ⦠+
, I do recommend that you get a less antique tool suite (such as Cygwin, which includes git and a whole lot more, or GNUwin32, which lacks git but doesn't have the bad-employee-trying-to-use-linux-but-we-impose-windows vibe that Cygwin gives). This feature was added in version 4.2.12, over 9 years ago (it was the last identified feature to make GNU find
POSIX-compliant).
If you want to stick to an older GNU find, you can use -print0
with xargs -0
to get a similar functionality: grouped command execution, supporting arbitrary file names.
find a/folder b/folder -name '*.c' -o -name '*.h' -print0 | xargs -0 grep -I foobar /dev/null
Always quote the wildcards on the find
command line. Otherwise, if you happen to run this command from a directory containing .c
files, the unquoted *.c
would be expanded to the list of .c
files in the current directory.
Adding /dev/null
to the grep
command line is a trick to ensure that grep will always print the file name, even if find
happens to find a single match. With GNU find, another method is to pass the option -H
.
What do you mean by bad-employee-trying-to-use-linux-but-we-impose-windows vibe that cygwin gives?
â David Kennedy
May 16 '14 at 20:36
GNUwin32 doesn't have expect :(
â David Kennedy
May 17 '14 at 16:18
add a comment |Â
up vote
0
down vote
when I was using like following way
"$sudo find . -type f -perm 0777 -exec chmod 644 ;"
then I was getting this error "find: missing argument to `-exec' "
when I did bit space between '' and ''. It got fixed .
"sudo find . -type f -perm 0777 -print -exec chmod 644 ;"
add a comment |Â
up vote
-1
down vote
I had my share of headaches with the exec syntax in the past. most days now I prefer the nicer bash syntax:
for f in `find a/folder b/folder -name "*.[ch]"`; do grep -I foobar $f; done
It has some limitations when you want to treat the files as a group, as each is evaluated serially, but you can pipe the output elsewhere just fine
1
While this tends to work it is significantly less useful than the pure-find version because it cannot handle files with whitespace in the name correctly.
â Etan Reisner
May 8 '14 at 3:35
3
No, don't do this. This breaks as soon as the files contain spaces and other âÂÂweirdâ characters. This is also more complex and slower thanfind ⦠-exec ⦠;
, so there's no reason to use this even if you know that your file names are tame.
â Gilles
May 8 '14 at 3:44
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
accepted
You need to remove the backticks you use around . The command can be simplified like this:
find a/folder b/folder -name "*.[ch]" -exec grep -I foobar +
Should you use an archaic GNU find version, this should still work:
find a/folder b/folder -name "*.[ch]" -exec grep -I foobar ;
Oops, they were meant to be quotes not backticks.
â David Kennedy
May 7 '14 at 21:21
Quotes would be useless ashas no specific meaning to the shell.
â jlliagre
May 7 '14 at 21:26
From find man pages: "The string '' is replaced by the current file name being processed everywhere it occurs in the arguments to the command, not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped (with a '') or quoted to protect them from expansion by the shell."
â David Kennedy
May 7 '14 at 21:29
1
I indeed read that in the manual page but the fact is there is no shell I'm aware of that requires quoting the curly braces. What shell are you using ?
â jlliagre
May 7 '14 at 21:37
bash. With or without the quotes I get the error anyways.
â David Kennedy
May 7 '14 at 21:38
 |Â
show 4 more comments
up vote
7
down vote
accepted
You need to remove the backticks you use around . The command can be simplified like this:
find a/folder b/folder -name "*.[ch]" -exec grep -I foobar +
Should you use an archaic GNU find version, this should still work:
find a/folder b/folder -name "*.[ch]" -exec grep -I foobar ;
Oops, they were meant to be quotes not backticks.
â David Kennedy
May 7 '14 at 21:21
Quotes would be useless ashas no specific meaning to the shell.
â jlliagre
May 7 '14 at 21:26
From find man pages: "The string '' is replaced by the current file name being processed everywhere it occurs in the arguments to the command, not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped (with a '') or quoted to protect them from expansion by the shell."
â David Kennedy
May 7 '14 at 21:29
1
I indeed read that in the manual page but the fact is there is no shell I'm aware of that requires quoting the curly braces. What shell are you using ?
â jlliagre
May 7 '14 at 21:37
bash. With or without the quotes I get the error anyways.
â David Kennedy
May 7 '14 at 21:38
 |Â
show 4 more comments
up vote
7
down vote
accepted
up vote
7
down vote
accepted
You need to remove the backticks you use around . The command can be simplified like this:
find a/folder b/folder -name "*.[ch]" -exec grep -I foobar +
Should you use an archaic GNU find version, this should still work:
find a/folder b/folder -name "*.[ch]" -exec grep -I foobar ;
You need to remove the backticks you use around . The command can be simplified like this:
find a/folder b/folder -name "*.[ch]" -exec grep -I foobar +
Should you use an archaic GNU find version, this should still work:
find a/folder b/folder -name "*.[ch]" -exec grep -I foobar ;
edited Sep 11 '15 at 7:34
answered May 7 '14 at 21:18
jlliagre
45.2k578125
45.2k578125
Oops, they were meant to be quotes not backticks.
â David Kennedy
May 7 '14 at 21:21
Quotes would be useless ashas no specific meaning to the shell.
â jlliagre
May 7 '14 at 21:26
From find man pages: "The string '' is replaced by the current file name being processed everywhere it occurs in the arguments to the command, not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped (with a '') or quoted to protect them from expansion by the shell."
â David Kennedy
May 7 '14 at 21:29
1
I indeed read that in the manual page but the fact is there is no shell I'm aware of that requires quoting the curly braces. What shell are you using ?
â jlliagre
May 7 '14 at 21:37
bash. With or without the quotes I get the error anyways.
â David Kennedy
May 7 '14 at 21:38
 |Â
show 4 more comments
Oops, they were meant to be quotes not backticks.
â David Kennedy
May 7 '14 at 21:21
Quotes would be useless ashas no specific meaning to the shell.
â jlliagre
May 7 '14 at 21:26
From find man pages: "The string '' is replaced by the current file name being processed everywhere it occurs in the arguments to the command, not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped (with a '') or quoted to protect them from expansion by the shell."
â David Kennedy
May 7 '14 at 21:29
1
I indeed read that in the manual page but the fact is there is no shell I'm aware of that requires quoting the curly braces. What shell are you using ?
â jlliagre
May 7 '14 at 21:37
bash. With or without the quotes I get the error anyways.
â David Kennedy
May 7 '14 at 21:38
Oops, they were meant to be quotes not backticks.
â David Kennedy
May 7 '14 at 21:21
Oops, they were meant to be quotes not backticks.
â David Kennedy
May 7 '14 at 21:21
Quotes would be useless as
has no specific meaning to the shell.â jlliagre
May 7 '14 at 21:26
Quotes would be useless as
has no specific meaning to the shell.â jlliagre
May 7 '14 at 21:26
From find man pages: "The string '' is replaced by the current file name being processed everywhere it occurs in the arguments to the command, not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped (with a '') or quoted to protect them from expansion by the shell."
â David Kennedy
May 7 '14 at 21:29
From find man pages: "The string '' is replaced by the current file name being processed everywhere it occurs in the arguments to the command, not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped (with a '') or quoted to protect them from expansion by the shell."
â David Kennedy
May 7 '14 at 21:29
1
1
I indeed read that in the manual page but the fact is there is no shell I'm aware of that requires quoting the curly braces. What shell are you using ?
â jlliagre
May 7 '14 at 21:37
I indeed read that in the manual page but the fact is there is no shell I'm aware of that requires quoting the curly braces. What shell are you using ?
â jlliagre
May 7 '14 at 21:37
bash. With or without the quotes I get the error anyways.
â David Kennedy
May 7 '14 at 21:38
bash. With or without the quotes I get the error anyways.
â David Kennedy
May 7 '14 at 21:38
 |Â
show 4 more comments
up vote
3
down vote
âÂÂmissing argument to -exec
â usually means that the argument to -exec
is missing its terminator. The terminator must either be an argument containing just the character ;
(which needs to be quoted in a shell command, so it's typically written ;
or ';'
), or two successive arguments containing and
+
.
Stephane Chazelas has identified that you're using an older version of GNU find which doesn't support -exec ⦠+
, only -exec ;
. Although GNU was a late adopter of -exec ⦠+
, I do recommend that you get a less antique tool suite (such as Cygwin, which includes git and a whole lot more, or GNUwin32, which lacks git but doesn't have the bad-employee-trying-to-use-linux-but-we-impose-windows vibe that Cygwin gives). This feature was added in version 4.2.12, over 9 years ago (it was the last identified feature to make GNU find
POSIX-compliant).
If you want to stick to an older GNU find, you can use -print0
with xargs -0
to get a similar functionality: grouped command execution, supporting arbitrary file names.
find a/folder b/folder -name '*.c' -o -name '*.h' -print0 | xargs -0 grep -I foobar /dev/null
Always quote the wildcards on the find
command line. Otherwise, if you happen to run this command from a directory containing .c
files, the unquoted *.c
would be expanded to the list of .c
files in the current directory.
Adding /dev/null
to the grep
command line is a trick to ensure that grep will always print the file name, even if find
happens to find a single match. With GNU find, another method is to pass the option -H
.
What do you mean by bad-employee-trying-to-use-linux-but-we-impose-windows vibe that cygwin gives?
â David Kennedy
May 16 '14 at 20:36
GNUwin32 doesn't have expect :(
â David Kennedy
May 17 '14 at 16:18
add a comment |Â
up vote
3
down vote
âÂÂmissing argument to -exec
â usually means that the argument to -exec
is missing its terminator. The terminator must either be an argument containing just the character ;
(which needs to be quoted in a shell command, so it's typically written ;
or ';'
), or two successive arguments containing and
+
.
Stephane Chazelas has identified that you're using an older version of GNU find which doesn't support -exec ⦠+
, only -exec ;
. Although GNU was a late adopter of -exec ⦠+
, I do recommend that you get a less antique tool suite (such as Cygwin, which includes git and a whole lot more, or GNUwin32, which lacks git but doesn't have the bad-employee-trying-to-use-linux-but-we-impose-windows vibe that Cygwin gives). This feature was added in version 4.2.12, over 9 years ago (it was the last identified feature to make GNU find
POSIX-compliant).
If you want to stick to an older GNU find, you can use -print0
with xargs -0
to get a similar functionality: grouped command execution, supporting arbitrary file names.
find a/folder b/folder -name '*.c' -o -name '*.h' -print0 | xargs -0 grep -I foobar /dev/null
Always quote the wildcards on the find
command line. Otherwise, if you happen to run this command from a directory containing .c
files, the unquoted *.c
would be expanded to the list of .c
files in the current directory.
Adding /dev/null
to the grep
command line is a trick to ensure that grep will always print the file name, even if find
happens to find a single match. With GNU find, another method is to pass the option -H
.
What do you mean by bad-employee-trying-to-use-linux-but-we-impose-windows vibe that cygwin gives?
â David Kennedy
May 16 '14 at 20:36
GNUwin32 doesn't have expect :(
â David Kennedy
May 17 '14 at 16:18
add a comment |Â
up vote
3
down vote
up vote
3
down vote
âÂÂmissing argument to -exec
â usually means that the argument to -exec
is missing its terminator. The terminator must either be an argument containing just the character ;
(which needs to be quoted in a shell command, so it's typically written ;
or ';'
), or two successive arguments containing and
+
.
Stephane Chazelas has identified that you're using an older version of GNU find which doesn't support -exec ⦠+
, only -exec ;
. Although GNU was a late adopter of -exec ⦠+
, I do recommend that you get a less antique tool suite (such as Cygwin, which includes git and a whole lot more, or GNUwin32, which lacks git but doesn't have the bad-employee-trying-to-use-linux-but-we-impose-windows vibe that Cygwin gives). This feature was added in version 4.2.12, over 9 years ago (it was the last identified feature to make GNU find
POSIX-compliant).
If you want to stick to an older GNU find, you can use -print0
with xargs -0
to get a similar functionality: grouped command execution, supporting arbitrary file names.
find a/folder b/folder -name '*.c' -o -name '*.h' -print0 | xargs -0 grep -I foobar /dev/null
Always quote the wildcards on the find
command line. Otherwise, if you happen to run this command from a directory containing .c
files, the unquoted *.c
would be expanded to the list of .c
files in the current directory.
Adding /dev/null
to the grep
command line is a trick to ensure that grep will always print the file name, even if find
happens to find a single match. With GNU find, another method is to pass the option -H
.
âÂÂmissing argument to -exec
â usually means that the argument to -exec
is missing its terminator. The terminator must either be an argument containing just the character ;
(which needs to be quoted in a shell command, so it's typically written ;
or ';'
), or two successive arguments containing and
+
.
Stephane Chazelas has identified that you're using an older version of GNU find which doesn't support -exec ⦠+
, only -exec ;
. Although GNU was a late adopter of -exec ⦠+
, I do recommend that you get a less antique tool suite (such as Cygwin, which includes git and a whole lot more, or GNUwin32, which lacks git but doesn't have the bad-employee-trying-to-use-linux-but-we-impose-windows vibe that Cygwin gives). This feature was added in version 4.2.12, over 9 years ago (it was the last identified feature to make GNU find
POSIX-compliant).
If you want to stick to an older GNU find, you can use -print0
with xargs -0
to get a similar functionality: grouped command execution, supporting arbitrary file names.
find a/folder b/folder -name '*.c' -o -name '*.h' -print0 | xargs -0 grep -I foobar /dev/null
Always quote the wildcards on the find
command line. Otherwise, if you happen to run this command from a directory containing .c
files, the unquoted *.c
would be expanded to the list of .c
files in the current directory.
Adding /dev/null
to the grep
command line is a trick to ensure that grep will always print the file name, even if find
happens to find a single match. With GNU find, another method is to pass the option -H
.
edited Apr 13 '17 at 12:36
Communityâ¦
1
1
answered May 8 '14 at 3:40
Gilles
509k12010071537
509k12010071537
What do you mean by bad-employee-trying-to-use-linux-but-we-impose-windows vibe that cygwin gives?
â David Kennedy
May 16 '14 at 20:36
GNUwin32 doesn't have expect :(
â David Kennedy
May 17 '14 at 16:18
add a comment |Â
What do you mean by bad-employee-trying-to-use-linux-but-we-impose-windows vibe that cygwin gives?
â David Kennedy
May 16 '14 at 20:36
GNUwin32 doesn't have expect :(
â David Kennedy
May 17 '14 at 16:18
What do you mean by bad-employee-trying-to-use-linux-but-we-impose-windows vibe that cygwin gives?
â David Kennedy
May 16 '14 at 20:36
What do you mean by bad-employee-trying-to-use-linux-but-we-impose-windows vibe that cygwin gives?
â David Kennedy
May 16 '14 at 20:36
GNUwin32 doesn't have expect :(
â David Kennedy
May 17 '14 at 16:18
GNUwin32 doesn't have expect :(
â David Kennedy
May 17 '14 at 16:18
add a comment |Â
up vote
0
down vote
when I was using like following way
"$sudo find . -type f -perm 0777 -exec chmod 644 ;"
then I was getting this error "find: missing argument to `-exec' "
when I did bit space between '' and ''. It got fixed .
"sudo find . -type f -perm 0777 -print -exec chmod 644 ;"
add a comment |Â
up vote
0
down vote
when I was using like following way
"$sudo find . -type f -perm 0777 -exec chmod 644 ;"
then I was getting this error "find: missing argument to `-exec' "
when I did bit space between '' and ''. It got fixed .
"sudo find . -type f -perm 0777 -print -exec chmod 644 ;"
add a comment |Â
up vote
0
down vote
up vote
0
down vote
when I was using like following way
"$sudo find . -type f -perm 0777 -exec chmod 644 ;"
then I was getting this error "find: missing argument to `-exec' "
when I did bit space between '' and ''. It got fixed .
"sudo find . -type f -perm 0777 -print -exec chmod 644 ;"
when I was using like following way
"$sudo find . -type f -perm 0777 -exec chmod 644 ;"
then I was getting this error "find: missing argument to `-exec' "
when I did bit space between '' and ''. It got fixed .
"sudo find . -type f -perm 0777 -print -exec chmod 644 ;"
answered Aug 17 at 9:21
ShreePool
1013
1013
add a comment |Â
add a comment |Â
up vote
-1
down vote
I had my share of headaches with the exec syntax in the past. most days now I prefer the nicer bash syntax:
for f in `find a/folder b/folder -name "*.[ch]"`; do grep -I foobar $f; done
It has some limitations when you want to treat the files as a group, as each is evaluated serially, but you can pipe the output elsewhere just fine
1
While this tends to work it is significantly less useful than the pure-find version because it cannot handle files with whitespace in the name correctly.
â Etan Reisner
May 8 '14 at 3:35
3
No, don't do this. This breaks as soon as the files contain spaces and other âÂÂweirdâ characters. This is also more complex and slower thanfind ⦠-exec ⦠;
, so there's no reason to use this even if you know that your file names are tame.
â Gilles
May 8 '14 at 3:44
add a comment |Â
up vote
-1
down vote
I had my share of headaches with the exec syntax in the past. most days now I prefer the nicer bash syntax:
for f in `find a/folder b/folder -name "*.[ch]"`; do grep -I foobar $f; done
It has some limitations when you want to treat the files as a group, as each is evaluated serially, but you can pipe the output elsewhere just fine
1
While this tends to work it is significantly less useful than the pure-find version because it cannot handle files with whitespace in the name correctly.
â Etan Reisner
May 8 '14 at 3:35
3
No, don't do this. This breaks as soon as the files contain spaces and other âÂÂweirdâ characters. This is also more complex and slower thanfind ⦠-exec ⦠;
, so there's no reason to use this even if you know that your file names are tame.
â Gilles
May 8 '14 at 3:44
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
I had my share of headaches with the exec syntax in the past. most days now I prefer the nicer bash syntax:
for f in `find a/folder b/folder -name "*.[ch]"`; do grep -I foobar $f; done
It has some limitations when you want to treat the files as a group, as each is evaluated serially, but you can pipe the output elsewhere just fine
I had my share of headaches with the exec syntax in the past. most days now I prefer the nicer bash syntax:
for f in `find a/folder b/folder -name "*.[ch]"`; do grep -I foobar $f; done
It has some limitations when you want to treat the files as a group, as each is evaluated serially, but you can pipe the output elsewhere just fine
answered May 8 '14 at 3:27
tolster710
111
111
1
While this tends to work it is significantly less useful than the pure-find version because it cannot handle files with whitespace in the name correctly.
â Etan Reisner
May 8 '14 at 3:35
3
No, don't do this. This breaks as soon as the files contain spaces and other âÂÂweirdâ characters. This is also more complex and slower thanfind ⦠-exec ⦠;
, so there's no reason to use this even if you know that your file names are tame.
â Gilles
May 8 '14 at 3:44
add a comment |Â
1
While this tends to work it is significantly less useful than the pure-find version because it cannot handle files with whitespace in the name correctly.
â Etan Reisner
May 8 '14 at 3:35
3
No, don't do this. This breaks as soon as the files contain spaces and other âÂÂweirdâ characters. This is also more complex and slower thanfind ⦠-exec ⦠;
, so there's no reason to use this even if you know that your file names are tame.
â Gilles
May 8 '14 at 3:44
1
1
While this tends to work it is significantly less useful than the pure-find version because it cannot handle files with whitespace in the name correctly.
â Etan Reisner
May 8 '14 at 3:35
While this tends to work it is significantly less useful than the pure-find version because it cannot handle files with whitespace in the name correctly.
â Etan Reisner
May 8 '14 at 3:35
3
3
No, don't do this. This breaks as soon as the files contain spaces and other âÂÂweirdâ characters. This is also more complex and slower than
find ⦠-exec ⦠;
, so there's no reason to use this even if you know that your file names are tame.â Gilles
May 8 '14 at 3:44
No, don't do this. This breaks as soon as the files contain spaces and other âÂÂweirdâ characters. This is also more complex and slower than
find ⦠-exec ⦠;
, so there's no reason to use this even if you know that your file names are tame.â Gilles
May 8 '14 at 3:44
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f128379%2ffind-missing-argument-to-exec%23new-answer', 'question_page');
);
Post as a guest
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
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
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
Have you tried escaping the
+
at the end?find a/folder b/folder -name *.c -o -name *.h -exec grep -I foobar '' +
â jayhendren
May 7 '14 at 21:37
Yes, no dice there either.
â David Kennedy
May 7 '14 at 21:39
1
You may be using an old version of GNU
find
. Though the-exec cmd +
variant is POSIX and has been available since the 80s, GNU find only added it (relatively) recently (2005). What doesfind --version
tell you?â Stéphane Chazelas
May 7 '14 at 21:43
GNU find version 4.1 - it's the one that ships with git for Windows.
â David Kennedy
May 7 '14 at 21:44
2
@Koveras, that would be it then.
-exec +
was added in 4.2.12 in 2005. In older GNU finds, you can use the (non-POSIX)-print0 | xargs -r0
to get something similar.4.1
is from 1994.â Stéphane Chazelas
May 7 '14 at 21:47