What is the difference between “…”, '…', $'…', and $“…” quotes?












17















Sometimes I see scripts use all of these different ways of quoting some text: "...", '...', $'...', and $"...". Why are there so many different kinds of quote being used?



Do they behave differently or affect what I can do inside them?










share|improve this question





























    17















    Sometimes I see scripts use all of these different ways of quoting some text: "...", '...', $'...', and $"...". Why are there so many different kinds of quote being used?



    Do they behave differently or affect what I can do inside them?










    share|improve this question



























      17












      17








      17


      3






      Sometimes I see scripts use all of these different ways of quoting some text: "...", '...', $'...', and $"...". Why are there so many different kinds of quote being used?



      Do they behave differently or affect what I can do inside them?










      share|improve this question
















      Sometimes I see scripts use all of these different ways of quoting some text: "...", '...', $'...', and $"...". Why are there so many different kinds of quote being used?



      Do they behave differently or affect what I can do inside them?







      bash shell-script shell zsh quoting






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 11 mins ago







      Michael Homer

















      asked 8 hours ago









      Michael HomerMichael Homer

      49.1k8131170




      49.1k8131170






















          1 Answer
          1






          active

          oldest

          votes


















          23














          All of these mean something different, and you can write different things inside them (or the same things, with different meaning). Different kinds of quote interpret different escape sequences inside them (something), or do or don't allow variable interpolations ($something) and other sorts of expansion inside them.



          In short:





          • '...' is entirely literal.


          • "..." allows both variables and embedded quote characters.


          • $'...' performs character escapes like n, but doesn't expand variables.


          • $"..." is for human-language translations in Bash.




          'Single quotes'



          Whatever you write between single quotes is treated literally and not processed at all. Backslashes and dollar signs have no special meaning there. This means you can't backslash-escape a character (including other single quotes!), interpolate a variable, or use any other shell feature.



          All of these examples result in literally what's written between the quotes:



          'hello world'                     => hello world
          '/pkg/bin:$PATH' => /pkg/bin:$PATH
          'hellonworld' => hellonworld
          '`echo abc`' => `echo abc`
          'I'dn't've' => Idn'tve


          The last one is complicated - there are two single-quoted strings run together with some unquoted text. The first one contains I. The unquoted text dn't contains a single quote that's escaped at the shell level, so it doesn't start a quoted string and is included as a literal character (so, dn't). The final quoted string is just ve. All of those get run together into a single word in the usual way the shell works.



          A somewhat-common idiom for combining literal text and variables is to run them together like that:



          'let x="'$PATH"


          will result in



          let x="/usr/bin:/bin"


          as a single word (better to double-quote $PATH as well just in case).





          "Double quotes"



          Inside double quotes, two sorts of expansion are processed, and you can use a backslash to escape characters to prevent expansions or escapes from being processed.



          There are two categories of expansion that happen inside double quotes:




          • Those starting with $ (parameter expansion $abc and ${abc}, command substitution $(...), and arithmetic expansion $((...)));

          • Command substitution with backquotes `abc`;


          Inside the quotes, a backslash can inhibit those expansions by putting it before the $ or `. It can also escape a closing double quote, so " includes just " in your string, or another backslash. Any other backslash is preserved literally - there are no escapes to produce other characters, and it isn't removed.



          Some of these examples act differently to before, and some don't:



          "hello world"                     => hello world
          "/pkg/bin:$PATH" => /pkg/bin:/bin:/usr/bin
          "hellonworld" => hellonworld
          "hello\nworld" => hellonworld
          "`echo abc`" => abc
          "I'dn't've" => I'dn't've
          "I'dn't've" => I'dn't've
          "I"dn"t've" => I"dn"t've




          $'ANSI-C quoting'



          This kind of quoting allows C-style backslash escapes to be processed, but not embedded variables or substitutions. It's the only kind of quoting that supports character escapes.



          This is an extension from ksh, now supported in Bash, zsh, and some other shells as well. It is not yet part of the POSIX standard and so maximally-portable scripts can't use it, but a Bash or ksh script is free to.



          All of these escapes can be used with their C meanings: a, b, f, n, r, t, v, and the literal escapes \, ', ", and ?. They also support the extensions e (escape character) and cx (what would be entered by Ctrl-x, e.g. cM is carriage return).



          It also allows four kinds of generic character escapes:





          • nnn, a single byte with octal value nnn


          • xHH, a single byte with hexadecimal value HH


          • uHHHH, the Unicode codepoint whose hexadecimal index is HHHH


          • UHHHHHHHH, the Unicode codepoint whose hexadecimal index is HHHHHHHH


          All of those digits are optional after the first one.



          $ and ` have no meaning and are preserved literally, so you can't include a variable there.



          $'hello world'                    => hello world
          $'/pkg/bin:$PATH' => /pkg/bin:$PATH
          $'hellonworld' => hello
          world
          $'`echo abc`' => `echo abc`
          $'I'dn't've' => I'dn't've
          $'U1f574u263A' => 🕴☺


          Most of these escapes you can simulate using the printf command, though POSIX only requires \, a, b, f, n, r, t, v, and nnn to work there. You can use command substitution to embed a printf inside double quotes if needed: "Path:$(printf 't')$PATH".





          $"Locale translation"



          This is a Bash-specific extension for localising natural-language textual strings, and looks up the part inside the quotes in a message catalog. It performs all the double quote expansions first. If the string isn't found in the translation database, it's used as its own translation. The built-in assumption is that the strings are in English.



          You probably don't want to use this one, but if you see it you can generally treat it as regular double quotes.





          One point of note is that there is no kind of quoting that allows both embedded parameter expansion and embedded character escapes. In most cases where you would want that, you'd be better off (safer) using printf:



          printf 'New path: e[1m%se[0m' "/pkg/bin:$PATH:"


          This clearly separates which parts are subject to character escaping and which are data values.



          Another is that all of these styles of quoting create a single "word" in the shell, unless $@ or an array expansion ${x[@]} is used inside double quotes. Both single-quote forms are always one word and never expanded any further.






          share|improve this answer


























          • A nice q&a. I've not come across the locale translation variant before. Might it be worth including a pointer to the process of adding a message catalogue?

            – roaima
            7 hours ago











          • @roaima It's in the linked documentation, but unfortunately the answer there is "it's system-dependent, but we're not going to tell you which system is which".

            – Michael Homer
            7 hours ago











          • Duh i didn't even realise until just this second that you'd linked the titles. Sorry!

            – roaima
            7 hours 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%2f503013%2fwhat-is-the-difference-between-and-quotes%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









          23














          All of these mean something different, and you can write different things inside them (or the same things, with different meaning). Different kinds of quote interpret different escape sequences inside them (something), or do or don't allow variable interpolations ($something) and other sorts of expansion inside them.



          In short:





          • '...' is entirely literal.


          • "..." allows both variables and embedded quote characters.


          • $'...' performs character escapes like n, but doesn't expand variables.


          • $"..." is for human-language translations in Bash.




          'Single quotes'



          Whatever you write between single quotes is treated literally and not processed at all. Backslashes and dollar signs have no special meaning there. This means you can't backslash-escape a character (including other single quotes!), interpolate a variable, or use any other shell feature.



          All of these examples result in literally what's written between the quotes:



          'hello world'                     => hello world
          '/pkg/bin:$PATH' => /pkg/bin:$PATH
          'hellonworld' => hellonworld
          '`echo abc`' => `echo abc`
          'I'dn't've' => Idn'tve


          The last one is complicated - there are two single-quoted strings run together with some unquoted text. The first one contains I. The unquoted text dn't contains a single quote that's escaped at the shell level, so it doesn't start a quoted string and is included as a literal character (so, dn't). The final quoted string is just ve. All of those get run together into a single word in the usual way the shell works.



          A somewhat-common idiom for combining literal text and variables is to run them together like that:



          'let x="'$PATH"


          will result in



          let x="/usr/bin:/bin"


          as a single word (better to double-quote $PATH as well just in case).





          "Double quotes"



          Inside double quotes, two sorts of expansion are processed, and you can use a backslash to escape characters to prevent expansions or escapes from being processed.



          There are two categories of expansion that happen inside double quotes:




          • Those starting with $ (parameter expansion $abc and ${abc}, command substitution $(...), and arithmetic expansion $((...)));

          • Command substitution with backquotes `abc`;


          Inside the quotes, a backslash can inhibit those expansions by putting it before the $ or `. It can also escape a closing double quote, so " includes just " in your string, or another backslash. Any other backslash is preserved literally - there are no escapes to produce other characters, and it isn't removed.



          Some of these examples act differently to before, and some don't:



          "hello world"                     => hello world
          "/pkg/bin:$PATH" => /pkg/bin:/bin:/usr/bin
          "hellonworld" => hellonworld
          "hello\nworld" => hellonworld
          "`echo abc`" => abc
          "I'dn't've" => I'dn't've
          "I'dn't've" => I'dn't've
          "I"dn"t've" => I"dn"t've




          $'ANSI-C quoting'



          This kind of quoting allows C-style backslash escapes to be processed, but not embedded variables or substitutions. It's the only kind of quoting that supports character escapes.



          This is an extension from ksh, now supported in Bash, zsh, and some other shells as well. It is not yet part of the POSIX standard and so maximally-portable scripts can't use it, but a Bash or ksh script is free to.



          All of these escapes can be used with their C meanings: a, b, f, n, r, t, v, and the literal escapes \, ', ", and ?. They also support the extensions e (escape character) and cx (what would be entered by Ctrl-x, e.g. cM is carriage return).



          It also allows four kinds of generic character escapes:





          • nnn, a single byte with octal value nnn


          • xHH, a single byte with hexadecimal value HH


          • uHHHH, the Unicode codepoint whose hexadecimal index is HHHH


          • UHHHHHHHH, the Unicode codepoint whose hexadecimal index is HHHHHHHH


          All of those digits are optional after the first one.



          $ and ` have no meaning and are preserved literally, so you can't include a variable there.



          $'hello world'                    => hello world
          $'/pkg/bin:$PATH' => /pkg/bin:$PATH
          $'hellonworld' => hello
          world
          $'`echo abc`' => `echo abc`
          $'I'dn't've' => I'dn't've
          $'U1f574u263A' => 🕴☺


          Most of these escapes you can simulate using the printf command, though POSIX only requires \, a, b, f, n, r, t, v, and nnn to work there. You can use command substitution to embed a printf inside double quotes if needed: "Path:$(printf 't')$PATH".





          $"Locale translation"



          This is a Bash-specific extension for localising natural-language textual strings, and looks up the part inside the quotes in a message catalog. It performs all the double quote expansions first. If the string isn't found in the translation database, it's used as its own translation. The built-in assumption is that the strings are in English.



          You probably don't want to use this one, but if you see it you can generally treat it as regular double quotes.





          One point of note is that there is no kind of quoting that allows both embedded parameter expansion and embedded character escapes. In most cases where you would want that, you'd be better off (safer) using printf:



          printf 'New path: e[1m%se[0m' "/pkg/bin:$PATH:"


          This clearly separates which parts are subject to character escaping and which are data values.



          Another is that all of these styles of quoting create a single "word" in the shell, unless $@ or an array expansion ${x[@]} is used inside double quotes. Both single-quote forms are always one word and never expanded any further.






          share|improve this answer


























          • A nice q&a. I've not come across the locale translation variant before. Might it be worth including a pointer to the process of adding a message catalogue?

            – roaima
            7 hours ago











          • @roaima It's in the linked documentation, but unfortunately the answer there is "it's system-dependent, but we're not going to tell you which system is which".

            – Michael Homer
            7 hours ago











          • Duh i didn't even realise until just this second that you'd linked the titles. Sorry!

            – roaima
            7 hours ago
















          23














          All of these mean something different, and you can write different things inside them (or the same things, with different meaning). Different kinds of quote interpret different escape sequences inside them (something), or do or don't allow variable interpolations ($something) and other sorts of expansion inside them.



          In short:





          • '...' is entirely literal.


          • "..." allows both variables and embedded quote characters.


          • $'...' performs character escapes like n, but doesn't expand variables.


          • $"..." is for human-language translations in Bash.




          'Single quotes'



          Whatever you write between single quotes is treated literally and not processed at all. Backslashes and dollar signs have no special meaning there. This means you can't backslash-escape a character (including other single quotes!), interpolate a variable, or use any other shell feature.



          All of these examples result in literally what's written between the quotes:



          'hello world'                     => hello world
          '/pkg/bin:$PATH' => /pkg/bin:$PATH
          'hellonworld' => hellonworld
          '`echo abc`' => `echo abc`
          'I'dn't've' => Idn'tve


          The last one is complicated - there are two single-quoted strings run together with some unquoted text. The first one contains I. The unquoted text dn't contains a single quote that's escaped at the shell level, so it doesn't start a quoted string and is included as a literal character (so, dn't). The final quoted string is just ve. All of those get run together into a single word in the usual way the shell works.



          A somewhat-common idiom for combining literal text and variables is to run them together like that:



          'let x="'$PATH"


          will result in



          let x="/usr/bin:/bin"


          as a single word (better to double-quote $PATH as well just in case).





          "Double quotes"



          Inside double quotes, two sorts of expansion are processed, and you can use a backslash to escape characters to prevent expansions or escapes from being processed.



          There are two categories of expansion that happen inside double quotes:




          • Those starting with $ (parameter expansion $abc and ${abc}, command substitution $(...), and arithmetic expansion $((...)));

          • Command substitution with backquotes `abc`;


          Inside the quotes, a backslash can inhibit those expansions by putting it before the $ or `. It can also escape a closing double quote, so " includes just " in your string, or another backslash. Any other backslash is preserved literally - there are no escapes to produce other characters, and it isn't removed.



          Some of these examples act differently to before, and some don't:



          "hello world"                     => hello world
          "/pkg/bin:$PATH" => /pkg/bin:/bin:/usr/bin
          "hellonworld" => hellonworld
          "hello\nworld" => hellonworld
          "`echo abc`" => abc
          "I'dn't've" => I'dn't've
          "I'dn't've" => I'dn't've
          "I"dn"t've" => I"dn"t've




          $'ANSI-C quoting'



          This kind of quoting allows C-style backslash escapes to be processed, but not embedded variables or substitutions. It's the only kind of quoting that supports character escapes.



          This is an extension from ksh, now supported in Bash, zsh, and some other shells as well. It is not yet part of the POSIX standard and so maximally-portable scripts can't use it, but a Bash or ksh script is free to.



          All of these escapes can be used with their C meanings: a, b, f, n, r, t, v, and the literal escapes \, ', ", and ?. They also support the extensions e (escape character) and cx (what would be entered by Ctrl-x, e.g. cM is carriage return).



          It also allows four kinds of generic character escapes:





          • nnn, a single byte with octal value nnn


          • xHH, a single byte with hexadecimal value HH


          • uHHHH, the Unicode codepoint whose hexadecimal index is HHHH


          • UHHHHHHHH, the Unicode codepoint whose hexadecimal index is HHHHHHHH


          All of those digits are optional after the first one.



          $ and ` have no meaning and are preserved literally, so you can't include a variable there.



          $'hello world'                    => hello world
          $'/pkg/bin:$PATH' => /pkg/bin:$PATH
          $'hellonworld' => hello
          world
          $'`echo abc`' => `echo abc`
          $'I'dn't've' => I'dn't've
          $'U1f574u263A' => 🕴☺


          Most of these escapes you can simulate using the printf command, though POSIX only requires \, a, b, f, n, r, t, v, and nnn to work there. You can use command substitution to embed a printf inside double quotes if needed: "Path:$(printf 't')$PATH".





          $"Locale translation"



          This is a Bash-specific extension for localising natural-language textual strings, and looks up the part inside the quotes in a message catalog. It performs all the double quote expansions first. If the string isn't found in the translation database, it's used as its own translation. The built-in assumption is that the strings are in English.



          You probably don't want to use this one, but if you see it you can generally treat it as regular double quotes.





          One point of note is that there is no kind of quoting that allows both embedded parameter expansion and embedded character escapes. In most cases where you would want that, you'd be better off (safer) using printf:



          printf 'New path: e[1m%se[0m' "/pkg/bin:$PATH:"


          This clearly separates which parts are subject to character escaping and which are data values.



          Another is that all of these styles of quoting create a single "word" in the shell, unless $@ or an array expansion ${x[@]} is used inside double quotes. Both single-quote forms are always one word and never expanded any further.






          share|improve this answer


























          • A nice q&a. I've not come across the locale translation variant before. Might it be worth including a pointer to the process of adding a message catalogue?

            – roaima
            7 hours ago











          • @roaima It's in the linked documentation, but unfortunately the answer there is "it's system-dependent, but we're not going to tell you which system is which".

            – Michael Homer
            7 hours ago











          • Duh i didn't even realise until just this second that you'd linked the titles. Sorry!

            – roaima
            7 hours ago














          23












          23








          23







          All of these mean something different, and you can write different things inside them (or the same things, with different meaning). Different kinds of quote interpret different escape sequences inside them (something), or do or don't allow variable interpolations ($something) and other sorts of expansion inside them.



          In short:





          • '...' is entirely literal.


          • "..." allows both variables and embedded quote characters.


          • $'...' performs character escapes like n, but doesn't expand variables.


          • $"..." is for human-language translations in Bash.




          'Single quotes'



          Whatever you write between single quotes is treated literally and not processed at all. Backslashes and dollar signs have no special meaning there. This means you can't backslash-escape a character (including other single quotes!), interpolate a variable, or use any other shell feature.



          All of these examples result in literally what's written between the quotes:



          'hello world'                     => hello world
          '/pkg/bin:$PATH' => /pkg/bin:$PATH
          'hellonworld' => hellonworld
          '`echo abc`' => `echo abc`
          'I'dn't've' => Idn'tve


          The last one is complicated - there are two single-quoted strings run together with some unquoted text. The first one contains I. The unquoted text dn't contains a single quote that's escaped at the shell level, so it doesn't start a quoted string and is included as a literal character (so, dn't). The final quoted string is just ve. All of those get run together into a single word in the usual way the shell works.



          A somewhat-common idiom for combining literal text and variables is to run them together like that:



          'let x="'$PATH"


          will result in



          let x="/usr/bin:/bin"


          as a single word (better to double-quote $PATH as well just in case).





          "Double quotes"



          Inside double quotes, two sorts of expansion are processed, and you can use a backslash to escape characters to prevent expansions or escapes from being processed.



          There are two categories of expansion that happen inside double quotes:




          • Those starting with $ (parameter expansion $abc and ${abc}, command substitution $(...), and arithmetic expansion $((...)));

          • Command substitution with backquotes `abc`;


          Inside the quotes, a backslash can inhibit those expansions by putting it before the $ or `. It can also escape a closing double quote, so " includes just " in your string, or another backslash. Any other backslash is preserved literally - there are no escapes to produce other characters, and it isn't removed.



          Some of these examples act differently to before, and some don't:



          "hello world"                     => hello world
          "/pkg/bin:$PATH" => /pkg/bin:/bin:/usr/bin
          "hellonworld" => hellonworld
          "hello\nworld" => hellonworld
          "`echo abc`" => abc
          "I'dn't've" => I'dn't've
          "I'dn't've" => I'dn't've
          "I"dn"t've" => I"dn"t've




          $'ANSI-C quoting'



          This kind of quoting allows C-style backslash escapes to be processed, but not embedded variables or substitutions. It's the only kind of quoting that supports character escapes.



          This is an extension from ksh, now supported in Bash, zsh, and some other shells as well. It is not yet part of the POSIX standard and so maximally-portable scripts can't use it, but a Bash or ksh script is free to.



          All of these escapes can be used with their C meanings: a, b, f, n, r, t, v, and the literal escapes \, ', ", and ?. They also support the extensions e (escape character) and cx (what would be entered by Ctrl-x, e.g. cM is carriage return).



          It also allows four kinds of generic character escapes:





          • nnn, a single byte with octal value nnn


          • xHH, a single byte with hexadecimal value HH


          • uHHHH, the Unicode codepoint whose hexadecimal index is HHHH


          • UHHHHHHHH, the Unicode codepoint whose hexadecimal index is HHHHHHHH


          All of those digits are optional after the first one.



          $ and ` have no meaning and are preserved literally, so you can't include a variable there.



          $'hello world'                    => hello world
          $'/pkg/bin:$PATH' => /pkg/bin:$PATH
          $'hellonworld' => hello
          world
          $'`echo abc`' => `echo abc`
          $'I'dn't've' => I'dn't've
          $'U1f574u263A' => 🕴☺


          Most of these escapes you can simulate using the printf command, though POSIX only requires \, a, b, f, n, r, t, v, and nnn to work there. You can use command substitution to embed a printf inside double quotes if needed: "Path:$(printf 't')$PATH".





          $"Locale translation"



          This is a Bash-specific extension for localising natural-language textual strings, and looks up the part inside the quotes in a message catalog. It performs all the double quote expansions first. If the string isn't found in the translation database, it's used as its own translation. The built-in assumption is that the strings are in English.



          You probably don't want to use this one, but if you see it you can generally treat it as regular double quotes.





          One point of note is that there is no kind of quoting that allows both embedded parameter expansion and embedded character escapes. In most cases where you would want that, you'd be better off (safer) using printf:



          printf 'New path: e[1m%se[0m' "/pkg/bin:$PATH:"


          This clearly separates which parts are subject to character escaping and which are data values.



          Another is that all of these styles of quoting create a single "word" in the shell, unless $@ or an array expansion ${x[@]} is used inside double quotes. Both single-quote forms are always one word and never expanded any further.






          share|improve this answer















          All of these mean something different, and you can write different things inside them (or the same things, with different meaning). Different kinds of quote interpret different escape sequences inside them (something), or do or don't allow variable interpolations ($something) and other sorts of expansion inside them.



          In short:





          • '...' is entirely literal.


          • "..." allows both variables and embedded quote characters.


          • $'...' performs character escapes like n, but doesn't expand variables.


          • $"..." is for human-language translations in Bash.




          'Single quotes'



          Whatever you write between single quotes is treated literally and not processed at all. Backslashes and dollar signs have no special meaning there. This means you can't backslash-escape a character (including other single quotes!), interpolate a variable, or use any other shell feature.



          All of these examples result in literally what's written between the quotes:



          'hello world'                     => hello world
          '/pkg/bin:$PATH' => /pkg/bin:$PATH
          'hellonworld' => hellonworld
          '`echo abc`' => `echo abc`
          'I'dn't've' => Idn'tve


          The last one is complicated - there are two single-quoted strings run together with some unquoted text. The first one contains I. The unquoted text dn't contains a single quote that's escaped at the shell level, so it doesn't start a quoted string and is included as a literal character (so, dn't). The final quoted string is just ve. All of those get run together into a single word in the usual way the shell works.



          A somewhat-common idiom for combining literal text and variables is to run them together like that:



          'let x="'$PATH"


          will result in



          let x="/usr/bin:/bin"


          as a single word (better to double-quote $PATH as well just in case).





          "Double quotes"



          Inside double quotes, two sorts of expansion are processed, and you can use a backslash to escape characters to prevent expansions or escapes from being processed.



          There are two categories of expansion that happen inside double quotes:




          • Those starting with $ (parameter expansion $abc and ${abc}, command substitution $(...), and arithmetic expansion $((...)));

          • Command substitution with backquotes `abc`;


          Inside the quotes, a backslash can inhibit those expansions by putting it before the $ or `. It can also escape a closing double quote, so " includes just " in your string, or another backslash. Any other backslash is preserved literally - there are no escapes to produce other characters, and it isn't removed.



          Some of these examples act differently to before, and some don't:



          "hello world"                     => hello world
          "/pkg/bin:$PATH" => /pkg/bin:/bin:/usr/bin
          "hellonworld" => hellonworld
          "hello\nworld" => hellonworld
          "`echo abc`" => abc
          "I'dn't've" => I'dn't've
          "I'dn't've" => I'dn't've
          "I"dn"t've" => I"dn"t've




          $'ANSI-C quoting'



          This kind of quoting allows C-style backslash escapes to be processed, but not embedded variables or substitutions. It's the only kind of quoting that supports character escapes.



          This is an extension from ksh, now supported in Bash, zsh, and some other shells as well. It is not yet part of the POSIX standard and so maximally-portable scripts can't use it, but a Bash or ksh script is free to.



          All of these escapes can be used with their C meanings: a, b, f, n, r, t, v, and the literal escapes \, ', ", and ?. They also support the extensions e (escape character) and cx (what would be entered by Ctrl-x, e.g. cM is carriage return).



          It also allows four kinds of generic character escapes:





          • nnn, a single byte with octal value nnn


          • xHH, a single byte with hexadecimal value HH


          • uHHHH, the Unicode codepoint whose hexadecimal index is HHHH


          • UHHHHHHHH, the Unicode codepoint whose hexadecimal index is HHHHHHHH


          All of those digits are optional after the first one.



          $ and ` have no meaning and are preserved literally, so you can't include a variable there.



          $'hello world'                    => hello world
          $'/pkg/bin:$PATH' => /pkg/bin:$PATH
          $'hellonworld' => hello
          world
          $'`echo abc`' => `echo abc`
          $'I'dn't've' => I'dn't've
          $'U1f574u263A' => 🕴☺


          Most of these escapes you can simulate using the printf command, though POSIX only requires \, a, b, f, n, r, t, v, and nnn to work there. You can use command substitution to embed a printf inside double quotes if needed: "Path:$(printf 't')$PATH".





          $"Locale translation"



          This is a Bash-specific extension for localising natural-language textual strings, and looks up the part inside the quotes in a message catalog. It performs all the double quote expansions first. If the string isn't found in the translation database, it's used as its own translation. The built-in assumption is that the strings are in English.



          You probably don't want to use this one, but if you see it you can generally treat it as regular double quotes.





          One point of note is that there is no kind of quoting that allows both embedded parameter expansion and embedded character escapes. In most cases where you would want that, you'd be better off (safer) using printf:



          printf 'New path: e[1m%se[0m' "/pkg/bin:$PATH:"


          This clearly separates which parts are subject to character escaping and which are data values.



          Another is that all of these styles of quoting create a single "word" in the shell, unless $@ or an array expansion ${x[@]} is used inside double quotes. Both single-quote forms are always one word and never expanded any further.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 1 hour ago









          ilkkachu

          59.9k996169




          59.9k996169










          answered 8 hours ago









          Michael HomerMichael Homer

          49.1k8131170




          49.1k8131170













          • A nice q&a. I've not come across the locale translation variant before. Might it be worth including a pointer to the process of adding a message catalogue?

            – roaima
            7 hours ago











          • @roaima It's in the linked documentation, but unfortunately the answer there is "it's system-dependent, but we're not going to tell you which system is which".

            – Michael Homer
            7 hours ago











          • Duh i didn't even realise until just this second that you'd linked the titles. Sorry!

            – roaima
            7 hours ago



















          • A nice q&a. I've not come across the locale translation variant before. Might it be worth including a pointer to the process of adding a message catalogue?

            – roaima
            7 hours ago











          • @roaima It's in the linked documentation, but unfortunately the answer there is "it's system-dependent, but we're not going to tell you which system is which".

            – Michael Homer
            7 hours ago











          • Duh i didn't even realise until just this second that you'd linked the titles. Sorry!

            – roaima
            7 hours ago

















          A nice q&a. I've not come across the locale translation variant before. Might it be worth including a pointer to the process of adding a message catalogue?

          – roaima
          7 hours ago





          A nice q&a. I've not come across the locale translation variant before. Might it be worth including a pointer to the process of adding a message catalogue?

          – roaima
          7 hours ago













          @roaima It's in the linked documentation, but unfortunately the answer there is "it's system-dependent, but we're not going to tell you which system is which".

          – Michael Homer
          7 hours ago





          @roaima It's in the linked documentation, but unfortunately the answer there is "it's system-dependent, but we're not going to tell you which system is which".

          – Michael Homer
          7 hours ago













          Duh i didn't even realise until just this second that you'd linked the titles. Sorry!

          – roaima
          7 hours ago





          Duh i didn't even realise until just this second that you'd linked the titles. Sorry!

          – roaima
          7 hours 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.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f503013%2fwhat-is-the-difference-between-and-quotes%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

          Knooppunt Holsloot

          Altaar (religie)

          Gregoriusmis