find: missing argument to -exec

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
5
down vote

favorite
2












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









share|improve this question























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






  • 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















up vote
5
down vote

favorite
2












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









share|improve this question























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






  • 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













up vote
5
down vote

favorite
2









up vote
5
down vote

favorite
2






2





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









share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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






  • 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










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






  • 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











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 ;





share|improve this answer






















  • 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










  • 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

















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.






share|improve this answer






















  • 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

















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






share|improve this answer



























    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






    share|improve this answer
















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










    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',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    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%2f128379%2ffind-missing-argument-to-exec%23new-answer', 'question_page');

    );

    Post as a guest






























    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 ;





    share|improve this answer






















    • 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










    • 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














    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 ;





    share|improve this answer






















    • 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










    • 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












    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 ;





    share|improve this answer














    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 ;






    share|improve this answer














    share|improve this answer



    share|improve this answer








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






    • 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










    • 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






    • 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












    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.






    share|improve this answer






















    • 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














    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.






    share|improve this answer






















    • 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












    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.






    share|improve this answer














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







    share|improve this answer














    share|improve this answer



    share|improve this answer








    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
















    • 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










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






    share|improve this answer
























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






      share|improve this answer






















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






        share|improve this answer












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







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 17 at 9:21









        ShreePool

        1013




        1013




















            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






            share|improve this answer
















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














            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






            share|improve this answer
















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












            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






            share|improve this answer












            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







            share|improve this answer












            share|improve this answer



            share|improve this answer










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












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







            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

















             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?