What is the difference between “…”, '…', $'…', and $“…” quotes?
Sometimes I see scripts use all of these different ways of quoting some text. 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
add a comment |
Sometimes I see scripts use all of these different ways of quoting some text. 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
add a comment |
Sometimes I see scripts use all of these different ways of quoting some text. 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
Sometimes I see scripts use all of these different ways of quoting some text. 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
bash shell-script shell zsh quoting
edited 4 hours ago
Azor Ahai
13016
13016
asked 6 hours ago
Michael HomerMichael Homer
49.1k8131170
49.1k8131170
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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 liken
, 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.
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
5 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
5 hours ago
Duh i didn't even realise until just this second that you'd linked the titles. Sorry!
– roaima
5 hours ago
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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 liken
, 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.
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
5 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
5 hours ago
Duh i didn't even realise until just this second that you'd linked the titles. Sorry!
– roaima
5 hours ago
add a comment |
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 liken
, 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.
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
5 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
5 hours ago
Duh i didn't even realise until just this second that you'd linked the titles. Sorry!
– roaima
5 hours ago
add a comment |
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 liken
, 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.
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 liken
, 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.
edited 6 hours ago
answered 6 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
5 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
5 hours ago
Duh i didn't even realise until just this second that you'd linked the titles. Sorry!
– roaima
5 hours ago
add a comment |
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
5 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
5 hours ago
Duh i didn't even realise until just this second that you'd linked the titles. Sorry!
– roaima
5 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
5 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
5 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
5 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
5 hours ago
Duh i didn't even realise until just this second that you'd linked the titles. Sorry!
– roaima
5 hours ago
Duh i didn't even realise until just this second that you'd linked the titles. Sorry!
– roaima
5 hours ago
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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