Separator between command list and }
The Bash Manual says
{ list; }
Placing a list of commands between curly braces causes the list to be executed in the current shell context. No subshell is
created. The semicolon (or newline) following list is required.
The braces are reserved words, so they must be separated from the list
by blanks or other shell metacharacters.
The parentheses are operators, and are recognized as separate tokens
by the shell even if they are not separated from the list by
whitespace.
If I remove the semicolon, like this:
$ { date }
>
Why does it expect stdin input?
A metacharacter is a character that separates words.
The semicolon and whitespace are both "shell metacharacters". Why can't whitespace separate wordsdateand}? Why do we need a semicolon instead of a whitespace for separating the words?
bash
add a comment |
The Bash Manual says
{ list; }
Placing a list of commands between curly braces causes the list to be executed in the current shell context. No subshell is
created. The semicolon (or newline) following list is required.
The braces are reserved words, so they must be separated from the list
by blanks or other shell metacharacters.
The parentheses are operators, and are recognized as separate tokens
by the shell even if they are not separated from the list by
whitespace.
If I remove the semicolon, like this:
$ { date }
>
Why does it expect stdin input?
A metacharacter is a character that separates words.
The semicolon and whitespace are both "shell metacharacters". Why can't whitespace separate wordsdateand}? Why do we need a semicolon instead of a whitespace for separating the words?
bash
Apparently this is "due to historical reasons." I'd venture a guess it has something to do with how bash interprets function definitions or brace expansion
– Eli Heady
Mar 4 '16 at 21:57
add a comment |
The Bash Manual says
{ list; }
Placing a list of commands between curly braces causes the list to be executed in the current shell context. No subshell is
created. The semicolon (or newline) following list is required.
The braces are reserved words, so they must be separated from the list
by blanks or other shell metacharacters.
The parentheses are operators, and are recognized as separate tokens
by the shell even if they are not separated from the list by
whitespace.
If I remove the semicolon, like this:
$ { date }
>
Why does it expect stdin input?
A metacharacter is a character that separates words.
The semicolon and whitespace are both "shell metacharacters". Why can't whitespace separate wordsdateand}? Why do we need a semicolon instead of a whitespace for separating the words?
bash
The Bash Manual says
{ list; }
Placing a list of commands between curly braces causes the list to be executed in the current shell context. No subshell is
created. The semicolon (or newline) following list is required.
The braces are reserved words, so they must be separated from the list
by blanks or other shell metacharacters.
The parentheses are operators, and are recognized as separate tokens
by the shell even if they are not separated from the list by
whitespace.
If I remove the semicolon, like this:
$ { date }
>
Why does it expect stdin input?
A metacharacter is a character that separates words.
The semicolon and whitespace are both "shell metacharacters". Why can't whitespace separate wordsdateand}? Why do we need a semicolon instead of a whitespace for separating the words?
bash
bash
edited 28 mins ago
Jeff Schaller
41.5k1056132
41.5k1056132
asked Mar 4 '16 at 21:09
TimTim
27.1k78262472
27.1k78262472
Apparently this is "due to historical reasons." I'd venture a guess it has something to do with how bash interprets function definitions or brace expansion
– Eli Heady
Mar 4 '16 at 21:57
add a comment |
Apparently this is "due to historical reasons." I'd venture a guess it has something to do with how bash interprets function definitions or brace expansion
– Eli Heady
Mar 4 '16 at 21:57
Apparently this is "due to historical reasons." I'd venture a guess it has something to do with how bash interprets function definitions or brace expansion
– Eli Heady
Mar 4 '16 at 21:57
Apparently this is "due to historical reasons." I'd venture a guess it has something to do with how bash interprets function definitions or brace expansion
– Eli Heady
Mar 4 '16 at 21:57
add a comment |
2 Answers
2
active
oldest
votes
It's waiting for the closing
}. You've entered a list with one command,date }, and a newline, so you're still inside the command group and can either add another command to the list or terminate it.
So it's not waiting for standard input (exactly), it's waiting for you to complete the command you started on the first line. If you enter
}here, you'll (probably) get an error from thedatecommand saying that it doesn't understand "}".
{and}are valid arguments to common commands, as seen in point 1. For example,finduses{}as an argument.
Specifically, only exactly "
{" and "}" are reserved words. Reserved words in the shell only matter when they're given exactly as an entire word of their own, and only where they're specifically expected. The most important place they're expected is at the start of a command.
The semicolon or newline means that
}appears at the start of the next command in the list, where it can be recognised as a reserved word and given its special treatment. This is specified by POSIX for the shell grammar:
This rule also implies that reserved words are not recognized except in certain positions in the input, such as after a
<newline>or<semicolon>; the grammar presumes that if the reserved word is intended, it is properly delimited by the user
It would be annoying if "then", another reserved word, couldn't be used as a normal word, so that basically makes sense.
(and), by contrast, are operators, can appear anywhere, and need to be escaped if they're used for their literal values. This is essentially a historical artefact, and given a do-over perhaps a more consistent choice would be made in one direction or another, or perhaps a more complex parser would be mandated.
For Bash in particular, braces for command grouping also need to be distinguished from braces for brace expansion, and the parser makes an assumption that you're unlikely to be brace-expanding a command that starts with a space.
There is a choice whether to maintain corner-case historical compatibility or not, and some other shells, such as zsh, have cleverer parsers and are able to deal with { date } with the meaning you intended.
Thanks. Does your quote from POSIX mean that all the reserved words appear after a newline or semicolon? What about the reserved wordsinand]]which don't appear after a newline or semicolon?
– Tim
Mar 21 '16 at 0:36
@Tim "such as" implies that there are other locations, including the second word afterfor.]]is not a POSIX reserved word, but Bash treats it as a keyword that is expected somewhere after[[.
– Michael Homer
Mar 21 '16 at 0:46
"The semicolon or newline means that } appears at the start of the next command in the list". Since there must be a semicolon before}, is}itself a clause with empty command? Must the clauses in a command be separated by a semicolon or newline?
– Tim
Mar 21 '16 at 0:54
Items in a command list must be separated by semicolons or newlines.
– Michael Homer
Mar 21 '16 at 0:58
add a comment |
It is waiting for you to complete the command. The same that happens if you write an incomplete if or while or others:
$ if date
>
The command is clearly defined in the manual:
A{ list; }is a compound command:
Compound Commands
{ list; } list must be terminated with a newline or semicolon.
It is clearly stated there: "terminated with a newline or semicolon"
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%2f267706%2fseparator-between-command-list-and%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's waiting for the closing
}. You've entered a list with one command,date }, and a newline, so you're still inside the command group and can either add another command to the list or terminate it.
So it's not waiting for standard input (exactly), it's waiting for you to complete the command you started on the first line. If you enter
}here, you'll (probably) get an error from thedatecommand saying that it doesn't understand "}".
{and}are valid arguments to common commands, as seen in point 1. For example,finduses{}as an argument.
Specifically, only exactly "
{" and "}" are reserved words. Reserved words in the shell only matter when they're given exactly as an entire word of their own, and only where they're specifically expected. The most important place they're expected is at the start of a command.
The semicolon or newline means that
}appears at the start of the next command in the list, where it can be recognised as a reserved word and given its special treatment. This is specified by POSIX for the shell grammar:
This rule also implies that reserved words are not recognized except in certain positions in the input, such as after a
<newline>or<semicolon>; the grammar presumes that if the reserved word is intended, it is properly delimited by the user
It would be annoying if "then", another reserved word, couldn't be used as a normal word, so that basically makes sense.
(and), by contrast, are operators, can appear anywhere, and need to be escaped if they're used for their literal values. This is essentially a historical artefact, and given a do-over perhaps a more consistent choice would be made in one direction or another, or perhaps a more complex parser would be mandated.
For Bash in particular, braces for command grouping also need to be distinguished from braces for brace expansion, and the parser makes an assumption that you're unlikely to be brace-expanding a command that starts with a space.
There is a choice whether to maintain corner-case historical compatibility or not, and some other shells, such as zsh, have cleverer parsers and are able to deal with { date } with the meaning you intended.
Thanks. Does your quote from POSIX mean that all the reserved words appear after a newline or semicolon? What about the reserved wordsinand]]which don't appear after a newline or semicolon?
– Tim
Mar 21 '16 at 0:36
@Tim "such as" implies that there are other locations, including the second word afterfor.]]is not a POSIX reserved word, but Bash treats it as a keyword that is expected somewhere after[[.
– Michael Homer
Mar 21 '16 at 0:46
"The semicolon or newline means that } appears at the start of the next command in the list". Since there must be a semicolon before}, is}itself a clause with empty command? Must the clauses in a command be separated by a semicolon or newline?
– Tim
Mar 21 '16 at 0:54
Items in a command list must be separated by semicolons or newlines.
– Michael Homer
Mar 21 '16 at 0:58
add a comment |
It's waiting for the closing
}. You've entered a list with one command,date }, and a newline, so you're still inside the command group and can either add another command to the list or terminate it.
So it's not waiting for standard input (exactly), it's waiting for you to complete the command you started on the first line. If you enter
}here, you'll (probably) get an error from thedatecommand saying that it doesn't understand "}".
{and}are valid arguments to common commands, as seen in point 1. For example,finduses{}as an argument.
Specifically, only exactly "
{" and "}" are reserved words. Reserved words in the shell only matter when they're given exactly as an entire word of their own, and only where they're specifically expected. The most important place they're expected is at the start of a command.
The semicolon or newline means that
}appears at the start of the next command in the list, where it can be recognised as a reserved word and given its special treatment. This is specified by POSIX for the shell grammar:
This rule also implies that reserved words are not recognized except in certain positions in the input, such as after a
<newline>or<semicolon>; the grammar presumes that if the reserved word is intended, it is properly delimited by the user
It would be annoying if "then", another reserved word, couldn't be used as a normal word, so that basically makes sense.
(and), by contrast, are operators, can appear anywhere, and need to be escaped if they're used for their literal values. This is essentially a historical artefact, and given a do-over perhaps a more consistent choice would be made in one direction or another, or perhaps a more complex parser would be mandated.
For Bash in particular, braces for command grouping also need to be distinguished from braces for brace expansion, and the parser makes an assumption that you're unlikely to be brace-expanding a command that starts with a space.
There is a choice whether to maintain corner-case historical compatibility or not, and some other shells, such as zsh, have cleverer parsers and are able to deal with { date } with the meaning you intended.
Thanks. Does your quote from POSIX mean that all the reserved words appear after a newline or semicolon? What about the reserved wordsinand]]which don't appear after a newline or semicolon?
– Tim
Mar 21 '16 at 0:36
@Tim "such as" implies that there are other locations, including the second word afterfor.]]is not a POSIX reserved word, but Bash treats it as a keyword that is expected somewhere after[[.
– Michael Homer
Mar 21 '16 at 0:46
"The semicolon or newline means that } appears at the start of the next command in the list". Since there must be a semicolon before}, is}itself a clause with empty command? Must the clauses in a command be separated by a semicolon or newline?
– Tim
Mar 21 '16 at 0:54
Items in a command list must be separated by semicolons or newlines.
– Michael Homer
Mar 21 '16 at 0:58
add a comment |
It's waiting for the closing
}. You've entered a list with one command,date }, and a newline, so you're still inside the command group and can either add another command to the list or terminate it.
So it's not waiting for standard input (exactly), it's waiting for you to complete the command you started on the first line. If you enter
}here, you'll (probably) get an error from thedatecommand saying that it doesn't understand "}".
{and}are valid arguments to common commands, as seen in point 1. For example,finduses{}as an argument.
Specifically, only exactly "
{" and "}" are reserved words. Reserved words in the shell only matter when they're given exactly as an entire word of their own, and only where they're specifically expected. The most important place they're expected is at the start of a command.
The semicolon or newline means that
}appears at the start of the next command in the list, where it can be recognised as a reserved word and given its special treatment. This is specified by POSIX for the shell grammar:
This rule also implies that reserved words are not recognized except in certain positions in the input, such as after a
<newline>or<semicolon>; the grammar presumes that if the reserved word is intended, it is properly delimited by the user
It would be annoying if "then", another reserved word, couldn't be used as a normal word, so that basically makes sense.
(and), by contrast, are operators, can appear anywhere, and need to be escaped if they're used for their literal values. This is essentially a historical artefact, and given a do-over perhaps a more consistent choice would be made in one direction or another, or perhaps a more complex parser would be mandated.
For Bash in particular, braces for command grouping also need to be distinguished from braces for brace expansion, and the parser makes an assumption that you're unlikely to be brace-expanding a command that starts with a space.
There is a choice whether to maintain corner-case historical compatibility or not, and some other shells, such as zsh, have cleverer parsers and are able to deal with { date } with the meaning you intended.
It's waiting for the closing
}. You've entered a list with one command,date }, and a newline, so you're still inside the command group and can either add another command to the list or terminate it.
So it's not waiting for standard input (exactly), it's waiting for you to complete the command you started on the first line. If you enter
}here, you'll (probably) get an error from thedatecommand saying that it doesn't understand "}".
{and}are valid arguments to common commands, as seen in point 1. For example,finduses{}as an argument.
Specifically, only exactly "
{" and "}" are reserved words. Reserved words in the shell only matter when they're given exactly as an entire word of their own, and only where they're specifically expected. The most important place they're expected is at the start of a command.
The semicolon or newline means that
}appears at the start of the next command in the list, where it can be recognised as a reserved word and given its special treatment. This is specified by POSIX for the shell grammar:
This rule also implies that reserved words are not recognized except in certain positions in the input, such as after a
<newline>or<semicolon>; the grammar presumes that if the reserved word is intended, it is properly delimited by the user
It would be annoying if "then", another reserved word, couldn't be used as a normal word, so that basically makes sense.
(and), by contrast, are operators, can appear anywhere, and need to be escaped if they're used for their literal values. This is essentially a historical artefact, and given a do-over perhaps a more consistent choice would be made in one direction or another, or perhaps a more complex parser would be mandated.
For Bash in particular, braces for command grouping also need to be distinguished from braces for brace expansion, and the parser makes an assumption that you're unlikely to be brace-expanding a command that starts with a space.
There is a choice whether to maintain corner-case historical compatibility or not, and some other shells, such as zsh, have cleverer parsers and are able to deal with { date } with the meaning you intended.
edited Mar 4 '16 at 22:19
answered Mar 4 '16 at 22:13
Michael HomerMichael Homer
48.6k8130168
48.6k8130168
Thanks. Does your quote from POSIX mean that all the reserved words appear after a newline or semicolon? What about the reserved wordsinand]]which don't appear after a newline or semicolon?
– Tim
Mar 21 '16 at 0:36
@Tim "such as" implies that there are other locations, including the second word afterfor.]]is not a POSIX reserved word, but Bash treats it as a keyword that is expected somewhere after[[.
– Michael Homer
Mar 21 '16 at 0:46
"The semicolon or newline means that } appears at the start of the next command in the list". Since there must be a semicolon before}, is}itself a clause with empty command? Must the clauses in a command be separated by a semicolon or newline?
– Tim
Mar 21 '16 at 0:54
Items in a command list must be separated by semicolons or newlines.
– Michael Homer
Mar 21 '16 at 0:58
add a comment |
Thanks. Does your quote from POSIX mean that all the reserved words appear after a newline or semicolon? What about the reserved wordsinand]]which don't appear after a newline or semicolon?
– Tim
Mar 21 '16 at 0:36
@Tim "such as" implies that there are other locations, including the second word afterfor.]]is not a POSIX reserved word, but Bash treats it as a keyword that is expected somewhere after[[.
– Michael Homer
Mar 21 '16 at 0:46
"The semicolon or newline means that } appears at the start of the next command in the list". Since there must be a semicolon before}, is}itself a clause with empty command? Must the clauses in a command be separated by a semicolon or newline?
– Tim
Mar 21 '16 at 0:54
Items in a command list must be separated by semicolons or newlines.
– Michael Homer
Mar 21 '16 at 0:58
Thanks. Does your quote from POSIX mean that all the reserved words appear after a newline or semicolon? What about the reserved words
in and ]] which don't appear after a newline or semicolon?– Tim
Mar 21 '16 at 0:36
Thanks. Does your quote from POSIX mean that all the reserved words appear after a newline or semicolon? What about the reserved words
in and ]] which don't appear after a newline or semicolon?– Tim
Mar 21 '16 at 0:36
@Tim "such as" implies that there are other locations, including the second word after
for. ]] is not a POSIX reserved word, but Bash treats it as a keyword that is expected somewhere after [[.– Michael Homer
Mar 21 '16 at 0:46
@Tim "such as" implies that there are other locations, including the second word after
for. ]] is not a POSIX reserved word, but Bash treats it as a keyword that is expected somewhere after [[.– Michael Homer
Mar 21 '16 at 0:46
"The semicolon or newline means that } appears at the start of the next command in the list". Since there must be a semicolon before
}, is } itself a clause with empty command? Must the clauses in a command be separated by a semicolon or newline?– Tim
Mar 21 '16 at 0:54
"The semicolon or newline means that } appears at the start of the next command in the list". Since there must be a semicolon before
}, is } itself a clause with empty command? Must the clauses in a command be separated by a semicolon or newline?– Tim
Mar 21 '16 at 0:54
Items in a command list must be separated by semicolons or newlines.
– Michael Homer
Mar 21 '16 at 0:58
Items in a command list must be separated by semicolons or newlines.
– Michael Homer
Mar 21 '16 at 0:58
add a comment |
It is waiting for you to complete the command. The same that happens if you write an incomplete if or while or others:
$ if date
>
The command is clearly defined in the manual:
A{ list; }is a compound command:
Compound Commands
{ list; } list must be terminated with a newline or semicolon.
It is clearly stated there: "terminated with a newline or semicolon"
add a comment |
It is waiting for you to complete the command. The same that happens if you write an incomplete if or while or others:
$ if date
>
The command is clearly defined in the manual:
A{ list; }is a compound command:
Compound Commands
{ list; } list must be terminated with a newline or semicolon.
It is clearly stated there: "terminated with a newline or semicolon"
add a comment |
It is waiting for you to complete the command. The same that happens if you write an incomplete if or while or others:
$ if date
>
The command is clearly defined in the manual:
A{ list; }is a compound command:
Compound Commands
{ list; } list must be terminated with a newline or semicolon.
It is clearly stated there: "terminated with a newline or semicolon"
It is waiting for you to complete the command. The same that happens if you write an incomplete if or while or others:
$ if date
>
The command is clearly defined in the manual:
A{ list; }is a compound command:
Compound Commands
{ list; } list must be terminated with a newline or semicolon.
It is clearly stated there: "terminated with a newline or semicolon"
answered Mar 6 '16 at 2:20
user79743
add a comment |
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%2f267706%2fseparator-between-command-list-and%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
Apparently this is "due to historical reasons." I'd venture a guess it has something to do with how bash interprets function definitions or brace expansion
– Eli Heady
Mar 4 '16 at 21:57