What does the last “-” (hyphen) mean in options of `bash`?
In this tutorial we need to execute the following command:
# curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
What does the last -
(hyphen) after bash
mean?
I've seen a lot of commands with this, and couldn't find myself a logical explanation and neither find how to reformulate a google search for it. Is it the output of the piped command?
linux command-line bash pipe
add a comment |
In this tutorial we need to execute the following command:
# curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
What does the last -
(hyphen) after bash
mean?
I've seen a lot of commands with this, and couldn't find myself a logical explanation and neither find how to reformulate a google search for it. Is it the output of the piped command?
linux command-line bash pipe
add a comment |
In this tutorial we need to execute the following command:
# curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
What does the last -
(hyphen) after bash
mean?
I've seen a lot of commands with this, and couldn't find myself a logical explanation and neither find how to reformulate a google search for it. Is it the output of the piped command?
linux command-line bash pipe
In this tutorial we need to execute the following command:
# curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
What does the last -
(hyphen) after bash
mean?
I've seen a lot of commands with this, and couldn't find myself a logical explanation and neither find how to reformulate a google search for it. Is it the output of the piped command?
linux command-line bash pipe
linux command-line bash pipe
edited 1 hour ago
Kamil Maciorowski
24.1k155176
24.1k155176
asked 2 hours ago
Omar BISTAMI
255
255
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Bash behaves in somewhat non-standard way when it comes to -
.
POSIX says:
Guideline 10:
The first--
argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the-
character.
[…]
Guideline 13:
For utilities that use operands to represent files to be opened for either reading or writing, the-
operand should be used to mean only standard input (or standard output when it is clear from context that an output file is being specified) or a file named-
.
And
Where a utility described in the Shell and Utilities volume of POSIX.1-2017 as conforming to these guidelines is required to accept, or not to accept, the operand
-
to mean standard input or output, this usage is explained in the OPERANDS section. Otherwise, if such a utility uses operands to represent files, it is implementation-defined whether the operand-
stands for standard input (or standard output), or for a file named-
.
But then man 1 bash
reads:
A
--
signals the end of options and disables further option processing. Any arguments after the--
are treated as filenames and arguments. An argument of-
is equivalent to--
.
So for Bash -
means neither standard input nor a file, hence somewhat non-standard.
Now your particular case:
curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
I suspect the author of this command may not realize -
is equivalent to --
in this case. I suspect the author wanted to make sure bash
will read from its standard input, they expected -
to work according to the guideline 13.
But even if it worked according to the guideline, -
would be unnecessary here because bash
detects when its standard input is a pipe and acts accordingly (unless -c
is given etc.).
Yet -
doesn't work according to the guideline, it works like --
. Still --
is unnecessary here because there are no arguments after it.
In my opinion the last -
changes nothing. The command would work without it.
To see how --
and -
can be useful in general, study the example below.
cat
in my Kubuntu obeys both guidelines and I will use it to demonstrate usefulness of -
and --
.
Let a file named foo
exist. This will print the file:
cat foo
Let a file named --help
exist. This won't print the file:
cat --help
But this will print the file named --help
:
cat -- --help
This will concatenate the file named --help
with whatever comes from the standard input:
cat -- --help -
It seems you don't really need --
, because you can always pass ./--help
which will be interpreted as a file for sure. But consider
cat "$file"
when you don't know beforehand what the content of the variable is. You cannot just prepend ./
to it, because it may be an absolute path and ./
would break it. On the other hand it may be a file named --help
(because why not?). In this case --
is very useful; this is a lot more robust command:
cat -- "$file"
Thank your for your answer , is there any examples that can help explain it more in bash context ?
– Omar BISTAMI
2 hours ago
@OmarBISTAMI I have expanded my answer.
– Kamil Maciorowski
1 hour ago
add a comment |
In man bash
, at the end of the single-character options there is:-
-- A -- signals the end of options and disables further option processing.
Any arguments after the -- are treated as filenames and arguments. An
argument of - is equivalent to --.
If you have quoted the complete command, I can see no reason to use -
after bash
in this instance, but it does no harm.
Thank you for your answer, Yes i have quoted the complete command. so anything after - or -- will not be seen as an option but as a file name or arguments, could you please give an example where it is useful ?
– Omar BISTAMI
2 hours ago
It's really to allow for a script whose name begins-
, an unlikely requirement, but-
/--
makes it possible.
– AFH
1 hour ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2fsuperuser.com%2fquestions%2f1388584%2fwhat-does-the-last-hyphen-mean-in-options-of-bash%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
Bash behaves in somewhat non-standard way when it comes to -
.
POSIX says:
Guideline 10:
The first--
argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the-
character.
[…]
Guideline 13:
For utilities that use operands to represent files to be opened for either reading or writing, the-
operand should be used to mean only standard input (or standard output when it is clear from context that an output file is being specified) or a file named-
.
And
Where a utility described in the Shell and Utilities volume of POSIX.1-2017 as conforming to these guidelines is required to accept, or not to accept, the operand
-
to mean standard input or output, this usage is explained in the OPERANDS section. Otherwise, if such a utility uses operands to represent files, it is implementation-defined whether the operand-
stands for standard input (or standard output), or for a file named-
.
But then man 1 bash
reads:
A
--
signals the end of options and disables further option processing. Any arguments after the--
are treated as filenames and arguments. An argument of-
is equivalent to--
.
So for Bash -
means neither standard input nor a file, hence somewhat non-standard.
Now your particular case:
curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
I suspect the author of this command may not realize -
is equivalent to --
in this case. I suspect the author wanted to make sure bash
will read from its standard input, they expected -
to work according to the guideline 13.
But even if it worked according to the guideline, -
would be unnecessary here because bash
detects when its standard input is a pipe and acts accordingly (unless -c
is given etc.).
Yet -
doesn't work according to the guideline, it works like --
. Still --
is unnecessary here because there are no arguments after it.
In my opinion the last -
changes nothing. The command would work without it.
To see how --
and -
can be useful in general, study the example below.
cat
in my Kubuntu obeys both guidelines and I will use it to demonstrate usefulness of -
and --
.
Let a file named foo
exist. This will print the file:
cat foo
Let a file named --help
exist. This won't print the file:
cat --help
But this will print the file named --help
:
cat -- --help
This will concatenate the file named --help
with whatever comes from the standard input:
cat -- --help -
It seems you don't really need --
, because you can always pass ./--help
which will be interpreted as a file for sure. But consider
cat "$file"
when you don't know beforehand what the content of the variable is. You cannot just prepend ./
to it, because it may be an absolute path and ./
would break it. On the other hand it may be a file named --help
(because why not?). In this case --
is very useful; this is a lot more robust command:
cat -- "$file"
Thank your for your answer , is there any examples that can help explain it more in bash context ?
– Omar BISTAMI
2 hours ago
@OmarBISTAMI I have expanded my answer.
– Kamil Maciorowski
1 hour ago
add a comment |
Bash behaves in somewhat non-standard way when it comes to -
.
POSIX says:
Guideline 10:
The first--
argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the-
character.
[…]
Guideline 13:
For utilities that use operands to represent files to be opened for either reading or writing, the-
operand should be used to mean only standard input (or standard output when it is clear from context that an output file is being specified) or a file named-
.
And
Where a utility described in the Shell and Utilities volume of POSIX.1-2017 as conforming to these guidelines is required to accept, or not to accept, the operand
-
to mean standard input or output, this usage is explained in the OPERANDS section. Otherwise, if such a utility uses operands to represent files, it is implementation-defined whether the operand-
stands for standard input (or standard output), or for a file named-
.
But then man 1 bash
reads:
A
--
signals the end of options and disables further option processing. Any arguments after the--
are treated as filenames and arguments. An argument of-
is equivalent to--
.
So for Bash -
means neither standard input nor a file, hence somewhat non-standard.
Now your particular case:
curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
I suspect the author of this command may not realize -
is equivalent to --
in this case. I suspect the author wanted to make sure bash
will read from its standard input, they expected -
to work according to the guideline 13.
But even if it worked according to the guideline, -
would be unnecessary here because bash
detects when its standard input is a pipe and acts accordingly (unless -c
is given etc.).
Yet -
doesn't work according to the guideline, it works like --
. Still --
is unnecessary here because there are no arguments after it.
In my opinion the last -
changes nothing. The command would work without it.
To see how --
and -
can be useful in general, study the example below.
cat
in my Kubuntu obeys both guidelines and I will use it to demonstrate usefulness of -
and --
.
Let a file named foo
exist. This will print the file:
cat foo
Let a file named --help
exist. This won't print the file:
cat --help
But this will print the file named --help
:
cat -- --help
This will concatenate the file named --help
with whatever comes from the standard input:
cat -- --help -
It seems you don't really need --
, because you can always pass ./--help
which will be interpreted as a file for sure. But consider
cat "$file"
when you don't know beforehand what the content of the variable is. You cannot just prepend ./
to it, because it may be an absolute path and ./
would break it. On the other hand it may be a file named --help
(because why not?). In this case --
is very useful; this is a lot more robust command:
cat -- "$file"
Thank your for your answer , is there any examples that can help explain it more in bash context ?
– Omar BISTAMI
2 hours ago
@OmarBISTAMI I have expanded my answer.
– Kamil Maciorowski
1 hour ago
add a comment |
Bash behaves in somewhat non-standard way when it comes to -
.
POSIX says:
Guideline 10:
The first--
argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the-
character.
[…]
Guideline 13:
For utilities that use operands to represent files to be opened for either reading or writing, the-
operand should be used to mean only standard input (or standard output when it is clear from context that an output file is being specified) or a file named-
.
And
Where a utility described in the Shell and Utilities volume of POSIX.1-2017 as conforming to these guidelines is required to accept, or not to accept, the operand
-
to mean standard input or output, this usage is explained in the OPERANDS section. Otherwise, if such a utility uses operands to represent files, it is implementation-defined whether the operand-
stands for standard input (or standard output), or for a file named-
.
But then man 1 bash
reads:
A
--
signals the end of options and disables further option processing. Any arguments after the--
are treated as filenames and arguments. An argument of-
is equivalent to--
.
So for Bash -
means neither standard input nor a file, hence somewhat non-standard.
Now your particular case:
curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
I suspect the author of this command may not realize -
is equivalent to --
in this case. I suspect the author wanted to make sure bash
will read from its standard input, they expected -
to work according to the guideline 13.
But even if it worked according to the guideline, -
would be unnecessary here because bash
detects when its standard input is a pipe and acts accordingly (unless -c
is given etc.).
Yet -
doesn't work according to the guideline, it works like --
. Still --
is unnecessary here because there are no arguments after it.
In my opinion the last -
changes nothing. The command would work without it.
To see how --
and -
can be useful in general, study the example below.
cat
in my Kubuntu obeys both guidelines and I will use it to demonstrate usefulness of -
and --
.
Let a file named foo
exist. This will print the file:
cat foo
Let a file named --help
exist. This won't print the file:
cat --help
But this will print the file named --help
:
cat -- --help
This will concatenate the file named --help
with whatever comes from the standard input:
cat -- --help -
It seems you don't really need --
, because you can always pass ./--help
which will be interpreted as a file for sure. But consider
cat "$file"
when you don't know beforehand what the content of the variable is. You cannot just prepend ./
to it, because it may be an absolute path and ./
would break it. On the other hand it may be a file named --help
(because why not?). In this case --
is very useful; this is a lot more robust command:
cat -- "$file"
Bash behaves in somewhat non-standard way when it comes to -
.
POSIX says:
Guideline 10:
The first--
argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the-
character.
[…]
Guideline 13:
For utilities that use operands to represent files to be opened for either reading or writing, the-
operand should be used to mean only standard input (or standard output when it is clear from context that an output file is being specified) or a file named-
.
And
Where a utility described in the Shell and Utilities volume of POSIX.1-2017 as conforming to these guidelines is required to accept, or not to accept, the operand
-
to mean standard input or output, this usage is explained in the OPERANDS section. Otherwise, if such a utility uses operands to represent files, it is implementation-defined whether the operand-
stands for standard input (or standard output), or for a file named-
.
But then man 1 bash
reads:
A
--
signals the end of options and disables further option processing. Any arguments after the--
are treated as filenames and arguments. An argument of-
is equivalent to--
.
So for Bash -
means neither standard input nor a file, hence somewhat non-standard.
Now your particular case:
curl -sL https://rpm.nodesource.com/setup_6.x | sudo -E bash -
I suspect the author of this command may not realize -
is equivalent to --
in this case. I suspect the author wanted to make sure bash
will read from its standard input, they expected -
to work according to the guideline 13.
But even if it worked according to the guideline, -
would be unnecessary here because bash
detects when its standard input is a pipe and acts accordingly (unless -c
is given etc.).
Yet -
doesn't work according to the guideline, it works like --
. Still --
is unnecessary here because there are no arguments after it.
In my opinion the last -
changes nothing. The command would work without it.
To see how --
and -
can be useful in general, study the example below.
cat
in my Kubuntu obeys both guidelines and I will use it to demonstrate usefulness of -
and --
.
Let a file named foo
exist. This will print the file:
cat foo
Let a file named --help
exist. This won't print the file:
cat --help
But this will print the file named --help
:
cat -- --help
This will concatenate the file named --help
with whatever comes from the standard input:
cat -- --help -
It seems you don't really need --
, because you can always pass ./--help
which will be interpreted as a file for sure. But consider
cat "$file"
when you don't know beforehand what the content of the variable is. You cannot just prepend ./
to it, because it may be an absolute path and ./
would break it. On the other hand it may be a file named --help
(because why not?). In this case --
is very useful; this is a lot more robust command:
cat -- "$file"
edited 1 hour ago
answered 2 hours ago
Kamil Maciorowski
24.1k155176
24.1k155176
Thank your for your answer , is there any examples that can help explain it more in bash context ?
– Omar BISTAMI
2 hours ago
@OmarBISTAMI I have expanded my answer.
– Kamil Maciorowski
1 hour ago
add a comment |
Thank your for your answer , is there any examples that can help explain it more in bash context ?
– Omar BISTAMI
2 hours ago
@OmarBISTAMI I have expanded my answer.
– Kamil Maciorowski
1 hour ago
Thank your for your answer , is there any examples that can help explain it more in bash context ?
– Omar BISTAMI
2 hours ago
Thank your for your answer , is there any examples that can help explain it more in bash context ?
– Omar BISTAMI
2 hours ago
@OmarBISTAMI I have expanded my answer.
– Kamil Maciorowski
1 hour ago
@OmarBISTAMI I have expanded my answer.
– Kamil Maciorowski
1 hour ago
add a comment |
In man bash
, at the end of the single-character options there is:-
-- A -- signals the end of options and disables further option processing.
Any arguments after the -- are treated as filenames and arguments. An
argument of - is equivalent to --.
If you have quoted the complete command, I can see no reason to use -
after bash
in this instance, but it does no harm.
Thank you for your answer, Yes i have quoted the complete command. so anything after - or -- will not be seen as an option but as a file name or arguments, could you please give an example where it is useful ?
– Omar BISTAMI
2 hours ago
It's really to allow for a script whose name begins-
, an unlikely requirement, but-
/--
makes it possible.
– AFH
1 hour ago
add a comment |
In man bash
, at the end of the single-character options there is:-
-- A -- signals the end of options and disables further option processing.
Any arguments after the -- are treated as filenames and arguments. An
argument of - is equivalent to --.
If you have quoted the complete command, I can see no reason to use -
after bash
in this instance, but it does no harm.
Thank you for your answer, Yes i have quoted the complete command. so anything after - or -- will not be seen as an option but as a file name or arguments, could you please give an example where it is useful ?
– Omar BISTAMI
2 hours ago
It's really to allow for a script whose name begins-
, an unlikely requirement, but-
/--
makes it possible.
– AFH
1 hour ago
add a comment |
In man bash
, at the end of the single-character options there is:-
-- A -- signals the end of options and disables further option processing.
Any arguments after the -- are treated as filenames and arguments. An
argument of - is equivalent to --.
If you have quoted the complete command, I can see no reason to use -
after bash
in this instance, but it does no harm.
In man bash
, at the end of the single-character options there is:-
-- A -- signals the end of options and disables further option processing.
Any arguments after the -- are treated as filenames and arguments. An
argument of - is equivalent to --.
If you have quoted the complete command, I can see no reason to use -
after bash
in this instance, but it does no harm.
answered 2 hours ago
AFH
13.9k31938
13.9k31938
Thank you for your answer, Yes i have quoted the complete command. so anything after - or -- will not be seen as an option but as a file name or arguments, could you please give an example where it is useful ?
– Omar BISTAMI
2 hours ago
It's really to allow for a script whose name begins-
, an unlikely requirement, but-
/--
makes it possible.
– AFH
1 hour ago
add a comment |
Thank you for your answer, Yes i have quoted the complete command. so anything after - or -- will not be seen as an option but as a file name or arguments, could you please give an example where it is useful ?
– Omar BISTAMI
2 hours ago
It's really to allow for a script whose name begins-
, an unlikely requirement, but-
/--
makes it possible.
– AFH
1 hour ago
Thank you for your answer, Yes i have quoted the complete command. so anything after - or -- will not be seen as an option but as a file name or arguments, could you please give an example where it is useful ?
– Omar BISTAMI
2 hours ago
Thank you for your answer, Yes i have quoted the complete command. so anything after - or -- will not be seen as an option but as a file name or arguments, could you please give an example where it is useful ?
– Omar BISTAMI
2 hours ago
It's really to allow for a script whose name begins
-
, an unlikely requirement, but -
/--
makes it possible.– AFH
1 hour ago
It's really to allow for a script whose name begins
-
, an unlikely requirement, but -
/--
makes it possible.– AFH
1 hour ago
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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%2fsuperuser.com%2fquestions%2f1388584%2fwhat-does-the-last-hyphen-mean-in-options-of-bash%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