What does the last “-” (hyphen) mean in options of `bash`?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
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
5
Same question on Ask Ubuntu — with the same example!
– 200_success
Dec 30 '18 at 3:47
2
Downloading stuff from the network and piping it directly intosudo bash
sounds really scary. Try looking for a tutorial that doesn't encourage such practices.
– Henning Makholm
Dec 30 '18 at 16:43
Its the npm tutorial, but i do agree with you...
– Omar BISTAMI
Dec 30 '18 at 18:01
1
If you need to search for things with symbols in them, trysymbolhound.com
.
– Joe
Jan 1 at 5:04
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 Dec 28 '18 at 23:33
Kamil Maciorowski
29.3k156289
29.3k156289
asked Dec 28 '18 at 22:03
Omar BISTAMIOmar BISTAMI
927
927
5
Same question on Ask Ubuntu — with the same example!
– 200_success
Dec 30 '18 at 3:47
2
Downloading stuff from the network and piping it directly intosudo bash
sounds really scary. Try looking for a tutorial that doesn't encourage such practices.
– Henning Makholm
Dec 30 '18 at 16:43
Its the npm tutorial, but i do agree with you...
– Omar BISTAMI
Dec 30 '18 at 18:01
1
If you need to search for things with symbols in them, trysymbolhound.com
.
– Joe
Jan 1 at 5:04
add a comment |
5
Same question on Ask Ubuntu — with the same example!
– 200_success
Dec 30 '18 at 3:47
2
Downloading stuff from the network and piping it directly intosudo bash
sounds really scary. Try looking for a tutorial that doesn't encourage such practices.
– Henning Makholm
Dec 30 '18 at 16:43
Its the npm tutorial, but i do agree with you...
– Omar BISTAMI
Dec 30 '18 at 18:01
1
If you need to search for things with symbols in them, trysymbolhound.com
.
– Joe
Jan 1 at 5:04
5
5
Same question on Ask Ubuntu — with the same example!
– 200_success
Dec 30 '18 at 3:47
Same question on Ask Ubuntu — with the same example!
– 200_success
Dec 30 '18 at 3:47
2
2
Downloading stuff from the network and piping it directly into
sudo bash
sounds really scary. Try looking for a tutorial that doesn't encourage such practices.– Henning Makholm
Dec 30 '18 at 16:43
Downloading stuff from the network and piping it directly into
sudo bash
sounds really scary. Try looking for a tutorial that doesn't encourage such practices.– Henning Makholm
Dec 30 '18 at 16:43
Its the npm tutorial, but i do agree with you...
– Omar BISTAMI
Dec 30 '18 at 18:01
Its the npm tutorial, but i do agree with you...
– Omar BISTAMI
Dec 30 '18 at 18:01
1
1
If you need to search for things with symbols in them, try
symbolhound.com
.– Joe
Jan 1 at 5:04
If you need to search for things with symbols in them, try
symbolhound.com
.– Joe
Jan 1 at 5:04
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"
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
Dec 28 '18 at 22:27
1
It's really to allow for a script whose name begins-
, an unlikely requirement, but-
/--
makes it possible.
– AFH
Dec 28 '18 at 23:17
1
@OmarBISTAMI Quoting a command will affect how the shell expands it, but won't affect any of the arguments which follow it. If you extend the quotes around legitimate arguments, then they become part of the command name which isn't what you want either. There are some commands which take file names as arguments, but don't use standard input by default. A contrived example allows you to sandwich input (from a terminal or a pipe) between two files.cat file1 - file2 > file3
.
– Joe
Jan 1 at 5:31
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"
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"
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 Dec 28 '18 at 23:09
answered Dec 28 '18 at 22:30
Kamil MaciorowskiKamil Maciorowski
29.3k156289
29.3k156289
add a comment |
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
Dec 28 '18 at 22:27
1
It's really to allow for a script whose name begins-
, an unlikely requirement, but-
/--
makes it possible.
– AFH
Dec 28 '18 at 23:17
1
@OmarBISTAMI Quoting a command will affect how the shell expands it, but won't affect any of the arguments which follow it. If you extend the quotes around legitimate arguments, then they become part of the command name which isn't what you want either. There are some commands which take file names as arguments, but don't use standard input by default. A contrived example allows you to sandwich input (from a terminal or a pipe) between two files.cat file1 - file2 > file3
.
– Joe
Jan 1 at 5:31
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
Dec 28 '18 at 22:27
1
It's really to allow for a script whose name begins-
, an unlikely requirement, but-
/--
makes it possible.
– AFH
Dec 28 '18 at 23:17
1
@OmarBISTAMI Quoting a command will affect how the shell expands it, but won't affect any of the arguments which follow it. If you extend the quotes around legitimate arguments, then they become part of the command name which isn't what you want either. There are some commands which take file names as arguments, but don't use standard input by default. A contrived example allows you to sandwich input (from a terminal or a pipe) between two files.cat file1 - file2 > file3
.
– Joe
Jan 1 at 5:31
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 Dec 28 '18 at 22:21
AFHAFH
14.7k31939
14.7k31939
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
Dec 28 '18 at 22:27
1
It's really to allow for a script whose name begins-
, an unlikely requirement, but-
/--
makes it possible.
– AFH
Dec 28 '18 at 23:17
1
@OmarBISTAMI Quoting a command will affect how the shell expands it, but won't affect any of the arguments which follow it. If you extend the quotes around legitimate arguments, then they become part of the command name which isn't what you want either. There are some commands which take file names as arguments, but don't use standard input by default. A contrived example allows you to sandwich input (from a terminal or a pipe) between two files.cat file1 - file2 > file3
.
– Joe
Jan 1 at 5:31
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
Dec 28 '18 at 22:27
1
It's really to allow for a script whose name begins-
, an unlikely requirement, but-
/--
makes it possible.
– AFH
Dec 28 '18 at 23:17
1
@OmarBISTAMI Quoting a command will affect how the shell expands it, but won't affect any of the arguments which follow it. If you extend the quotes around legitimate arguments, then they become part of the command name which isn't what you want either. There are some commands which take file names as arguments, but don't use standard input by default. A contrived example allows you to sandwich input (from a terminal or a pipe) between two files.cat file1 - file2 > file3
.
– Joe
Jan 1 at 5:31
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
Dec 28 '18 at 22:27
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
Dec 28 '18 at 22:27
1
1
It's really to allow for a script whose name begins
-
, an unlikely requirement, but -
/--
makes it possible.– AFH
Dec 28 '18 at 23:17
It's really to allow for a script whose name begins
-
, an unlikely requirement, but -
/--
makes it possible.– AFH
Dec 28 '18 at 23:17
1
1
@OmarBISTAMI Quoting a command will affect how the shell expands it, but won't affect any of the arguments which follow it. If you extend the quotes around legitimate arguments, then they become part of the command name which isn't what you want either. There are some commands which take file names as arguments, but don't use standard input by default. A contrived example allows you to sandwich input (from a terminal or a pipe) between two files.
cat file1 - file2 > file3
.– Joe
Jan 1 at 5:31
@OmarBISTAMI Quoting a command will affect how the shell expands it, but won't affect any of the arguments which follow it. If you extend the quotes around legitimate arguments, then they become part of the command name which isn't what you want either. There are some commands which take file names as arguments, but don't use standard input by default. A contrived example allows you to sandwich input (from a terminal or a pipe) between two files.
cat file1 - file2 > file3
.– Joe
Jan 1 at 5:31
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.
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
5
Same question on Ask Ubuntu — with the same example!
– 200_success
Dec 30 '18 at 3:47
2
Downloading stuff from the network and piping it directly into
sudo bash
sounds really scary. Try looking for a tutorial that doesn't encourage such practices.– Henning Makholm
Dec 30 '18 at 16:43
Its the npm tutorial, but i do agree with you...
– Omar BISTAMI
Dec 30 '18 at 18:01
1
If you need to search for things with symbols in them, try
symbolhound.com
.– Joe
Jan 1 at 5:04