Prevent quote expansion in user-made function












1














I think the following bash code is self-explanatory (even if incorrect) :



tg() {
git add -A && git commit -m $1 && git push
}


But it seems not to work :



$ tg "create index for users"
error: pathspec 'index' did not match any file(s) known to git.
error: pathspec 'for' did not match any file(s) known to git.
error: pathspec 'users' did not match any file(s) known to git.


Obviously, the problem is that the quote was expanded and my middle command was read as git commit -m create index for users rather than git commit -m "create index for users"



What did I do wrong ? How can I fix this ?










share|improve this question



























    1














    I think the following bash code is self-explanatory (even if incorrect) :



    tg() {
    git add -A && git commit -m $1 && git push
    }


    But it seems not to work :



    $ tg "create index for users"
    error: pathspec 'index' did not match any file(s) known to git.
    error: pathspec 'for' did not match any file(s) known to git.
    error: pathspec 'users' did not match any file(s) known to git.


    Obviously, the problem is that the quote was expanded and my middle command was read as git commit -m create index for users rather than git commit -m "create index for users"



    What did I do wrong ? How can I fix this ?










    share|improve this question

























      1












      1








      1







      I think the following bash code is self-explanatory (even if incorrect) :



      tg() {
      git add -A && git commit -m $1 && git push
      }


      But it seems not to work :



      $ tg "create index for users"
      error: pathspec 'index' did not match any file(s) known to git.
      error: pathspec 'for' did not match any file(s) known to git.
      error: pathspec 'users' did not match any file(s) known to git.


      Obviously, the problem is that the quote was expanded and my middle command was read as git commit -m create index for users rather than git commit -m "create index for users"



      What did I do wrong ? How can I fix this ?










      share|improve this question













      I think the following bash code is self-explanatory (even if incorrect) :



      tg() {
      git add -A && git commit -m $1 && git push
      }


      But it seems not to work :



      $ tg "create index for users"
      error: pathspec 'index' did not match any file(s) known to git.
      error: pathspec 'for' did not match any file(s) known to git.
      error: pathspec 'users' did not match any file(s) known to git.


      Obviously, the problem is that the quote was expanded and my middle command was read as git commit -m create index for users rather than git commit -m "create index for users"



      What did I do wrong ? How can I fix this ?







      bash quoting






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 32 mins ago









      Ewan Delanoy

      1577




      1577






















          1 Answer
          1






          active

          oldest

          votes


















          3














          Double quote the expansion $1:



          tg() {
          git add -A &&
          git commit -m "$1" &&
          git push
          }


          By not quoting $1, the shell will split its value on whitespaces (the contents of $IFS) and the resulting words will additionally undergo filename globbing.



          Related:




          • Why does my shell script choke on whitespace or other special characters?

          • When is double-quoting necessary?

          • Security implications of forgetting to quote a variable in bash/POSIX shells






          share|improve this answer























          • Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?
            – Ewan Delanoy
            23 mins ago






          • 2




            @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.
            – Kusalananda
            19 mins ago












          • Got it, thx. I'll try your solution a few times and accept it if it works.
            – Ewan Delanoy
            17 mins ago








          • 1




            @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.
            – Sergiy Kolodyazhnyy
            17 mins ago








          • 1




            @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.
            – Kusalananda
            13 mins ago













          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%2f491999%2fprevent-quote-expansion-in-user-made-function%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          3














          Double quote the expansion $1:



          tg() {
          git add -A &&
          git commit -m "$1" &&
          git push
          }


          By not quoting $1, the shell will split its value on whitespaces (the contents of $IFS) and the resulting words will additionally undergo filename globbing.



          Related:




          • Why does my shell script choke on whitespace or other special characters?

          • When is double-quoting necessary?

          • Security implications of forgetting to quote a variable in bash/POSIX shells






          share|improve this answer























          • Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?
            – Ewan Delanoy
            23 mins ago






          • 2




            @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.
            – Kusalananda
            19 mins ago












          • Got it, thx. I'll try your solution a few times and accept it if it works.
            – Ewan Delanoy
            17 mins ago








          • 1




            @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.
            – Sergiy Kolodyazhnyy
            17 mins ago








          • 1




            @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.
            – Kusalananda
            13 mins ago


















          3














          Double quote the expansion $1:



          tg() {
          git add -A &&
          git commit -m "$1" &&
          git push
          }


          By not quoting $1, the shell will split its value on whitespaces (the contents of $IFS) and the resulting words will additionally undergo filename globbing.



          Related:




          • Why does my shell script choke on whitespace or other special characters?

          • When is double-quoting necessary?

          • Security implications of forgetting to quote a variable in bash/POSIX shells






          share|improve this answer























          • Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?
            – Ewan Delanoy
            23 mins ago






          • 2




            @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.
            – Kusalananda
            19 mins ago












          • Got it, thx. I'll try your solution a few times and accept it if it works.
            – Ewan Delanoy
            17 mins ago








          • 1




            @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.
            – Sergiy Kolodyazhnyy
            17 mins ago








          • 1




            @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.
            – Kusalananda
            13 mins ago
















          3












          3








          3






          Double quote the expansion $1:



          tg() {
          git add -A &&
          git commit -m "$1" &&
          git push
          }


          By not quoting $1, the shell will split its value on whitespaces (the contents of $IFS) and the resulting words will additionally undergo filename globbing.



          Related:




          • Why does my shell script choke on whitespace or other special characters?

          • When is double-quoting necessary?

          • Security implications of forgetting to quote a variable in bash/POSIX shells






          share|improve this answer














          Double quote the expansion $1:



          tg() {
          git add -A &&
          git commit -m "$1" &&
          git push
          }


          By not quoting $1, the shell will split its value on whitespaces (the contents of $IFS) and the resulting words will additionally undergo filename globbing.



          Related:




          • Why does my shell script choke on whitespace or other special characters?

          • When is double-quoting necessary?

          • Security implications of forgetting to quote a variable in bash/POSIX shells







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 14 mins ago

























          answered 27 mins ago









          Kusalananda

          121k16229372




          121k16229372












          • Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?
            – Ewan Delanoy
            23 mins ago






          • 2




            @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.
            – Kusalananda
            19 mins ago












          • Got it, thx. I'll try your solution a few times and accept it if it works.
            – Ewan Delanoy
            17 mins ago








          • 1




            @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.
            – Sergiy Kolodyazhnyy
            17 mins ago








          • 1




            @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.
            – Kusalananda
            13 mins ago




















          • Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?
            – Ewan Delanoy
            23 mins ago






          • 2




            @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.
            – Kusalananda
            19 mins ago












          • Got it, thx. I'll try your solution a few times and accept it if it works.
            – Ewan Delanoy
            17 mins ago








          • 1




            @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.
            – Sergiy Kolodyazhnyy
            17 mins ago








          • 1




            @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.
            – Kusalananda
            13 mins ago


















          Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?
          – Ewan Delanoy
          23 mins ago




          Thx for your help. I'm confused here : isn't "$1" supposed to be a "heredoc" string and variables inside it are supposed to be expanded ? For example, in the shell echo "$MYVAR" is equivalent to echo $MYVAR ?
          – Ewan Delanoy
          23 mins ago




          2




          2




          @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.
          – Kusalananda
          19 mins ago






          @EwanDelanoy You are not using any here-document in your code. A here-document is written utility <<TAG and terminated by TAG (TAG can be any string). It's a form of redirection. echo $var and echo "$var" are not equivalent for the same reasons as I mentioned in my answer. Test with var=*. When it comes to variable expansions and quoting, $var and $1 behaves the same.
          – Kusalananda
          19 mins ago














          Got it, thx. I'll try your solution a few times and accept it if it works.
          – Ewan Delanoy
          17 mins ago






          Got it, thx. I'll try your solution a few times and accept it if it works.
          – Ewan Delanoy
          17 mins ago






          1




          1




          @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.
          – Sergiy Kolodyazhnyy
          17 mins ago






          @EwanDelanoy If there's only one "word" and no whitespaces, then echo "$MYVAR" and echo $MYVAR will have same output. But if you have hello world then "$MYVAR" is treated as single word, $MYVAR is split into two words. In this case, this is trivial. If you do ls $MYVAR it can give you file not found if you're looking for hello world file, because ls will look for two files, hello and world, but ls "$MYVAR" will show you the file hello world.
          – Sergiy Kolodyazhnyy
          17 mins ago






          1




          1




          @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.
          – Kusalananda
          13 mins ago






          @SergiyKolodyazhnyy That first sentence is true only given that the word contains no filename globbing characters, and that IFS has the default value.
          – Kusalananda
          13 mins ago




















          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.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • 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%2f491999%2fprevent-quote-expansion-in-user-made-function%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

          404 Error Contact Form 7 ajax form submitting

          How to know if a Active Directory user can login interactively

          Refactoring coordinates for Minecraft Pi buildings written in Python