What is the difference between “…”, '…', $'…', and $“…” quotes?Difference between ' and " on...

Can we "borrow" our answers to populate our own websites?

Why is a temp table a more efficient solution to the Halloween Problem than an eager spool?

What makes papers publishable in top-tier journals?

What's the oldest plausible frozen specimen for a Jurassic Park style story-line?

Boss asked me to sign a resignation paper without a date on it along with my new contract

Is there a verb that means to inject with poison?

Difference in casting float to int, 32-bit C

How to delete duplicate text from a file?

What is a good reason for every spaceship to carry a weapon on board?

Potential client has a problematic employee I can't work with

How do you funnel food off a cutting board?

"Starve to death" Vs. "Starve to the point of death"

Why does magnet wire need to be insulated?

Coworker asking me to not bring cakes due to self control issue. What should I do?

Best way to strengthen a wheel?

When obtaining gender reassignment/plastic surgery overseas, is an emergency travel document required to return home?

Plausible reason for gold-digging ant

What species should be used for storage of human minds?

Why do we have to make "peinlich" start with a capital letter and also end with -s in this sentence?

Does it take energy to move something in a circle?

Why does the Sudarshana Chakra resemble a tantric yantra in this image?

Stuck on a Geometry Puzzle

Is there an expiration time for free invocations?

Am I correct in stating that the study of topology is purely theoretical?



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


Difference between ' and " on command line (bash)?What is wrong with my use of “find -print0”?Are ASCII escape sequences and control characters pairings part of a standard?Is there a way to get *actual* (uninterpreted) shell arguments in a function or script?When is double-quoting necessary?What is the difference between ' and "?What is the difference having double quotes or not in bashBash Script Parsing Argument not working correctlyWhat is the difference between kill , pkill and killallDefine string with the characters *, single quote and $Why do these bash fork bombs work differently and what is the significance of & in it?While comparing integer, string and binary in bash, which enclosing quotes (single or double) should I use and why?What situations exist where Bash variables should not be double quoted?













24















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





























    24















    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



























      24












      24








      24


      4






      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 6 hours ago







      Michael Homer

















      asked 14 hours ago









      Michael HomerMichael Homer

      49.1k8132170




      49.1k8132170






















          1 Answer
          1






          active

          oldest

          votes


















          31














          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





















          • 1





            @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
            13 hours ago






          • 1





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

            – roaima
            13 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









          31














          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





















          • 1





            @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
            13 hours ago






          • 1





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

            – roaima
            13 hours ago
















          31














          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





















          • 1





            @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
            13 hours ago






          • 1





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

            – roaima
            13 hours ago














          31












          31








          31







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









          ilkkachu

          59.9k997169




          59.9k997169










          answered 14 hours ago









          Michael HomerMichael Homer

          49.1k8132170




          49.1k8132170








          • 1





            @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
            13 hours ago






          • 1





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

            – roaima
            13 hours ago














          • 1





            @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
            13 hours ago






          • 1





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

            – roaima
            13 hours ago








          1




          1





          @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
          13 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
          13 hours ago




          1




          1





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

          – roaima
          13 hours ago





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

          – roaima
          13 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

          “%fieldName is a required field.”, in Magento2 REST API Call for GET Method Type The Next...

          How to change City field to a dropdown in Checkout step Magento 2Magento 2 : How to change UI field(s)...

          變成蝙蝠會怎樣? 參考資料 外部連結 导航菜单Thomas Nagel, "What is it like to be a...