Can't use exclamation mark (!) in bash?
I'm trying to use the curl command to access a http url with a exclamation mark (!) in its path. e.g:
curl -v "http://example.org/!287s87asdjh2/somepath/someresource"
the console replies with bash: ... event not found.
What is going on here? and what would be the proper syntax to escape the exclamation mark?
bash quoting special-characters
edited Mar 3 '12 at 23:38
Gilles
532k12810691594
asked Mar 3 '12 at 18:36
netbrainnetbrain
5131510
add a comment |
I'm trying to use the curl command to access a http url with a exclamation mark (!) in its path. e.g:
curl -v "http://example.org/!287s87asdjh2/somepath/someresource"
the console replies with bash: ... event not found.
What is going on here? and what would be the proper syntax to escape the exclamation mark?
bash quoting special-characters
edited Mar 3 '12 at 23:38
Gilles
532k12810691594
asked Mar 3 '12 at 18:36
netbrainnetbrain
5131510
Solved in bash 4.4+
– Isaac
Nov 23 '18 at 1:18
add a comment |
I'm trying to use the curl command to access a http url with a exclamation mark (!) in its path. e.g:
curl -v "http://example.org/!287s87asdjh2/somepath/someresource"
the console replies with bash: ... event not found.
What is going on here? and what would be the proper syntax to escape the exclamation mark?
bash quoting special-characters
edited Mar 3 '12 at 23:38
Gilles
532k12810691594
asked Mar 3 '12 at 18:36
netbrainnetbrain
5131510
I'm trying to use the curl command to access a http url with a exclamation mark (!) in its path. e.g:
curl -v "http://example.org/!287s87asdjh2/somepath/someresource"
the console replies with bash: ... event not found.
What is going on here? and what would be the proper syntax to escape the exclamation mark?
bash quoting special-characters
bash quoting special-characters
edited Mar 3 '12 at 23:38
Gilles
532k12810691594
asked Mar 3 '12 at 18:36
netbrainnetbrain
5131510
edited Mar 3 '12 at 23:38
Gilles
532k12810691594
asked Mar 3 '12 at 18:36
netbrainnetbrain
5131510
edited Mar 3 '12 at 23:38
Gilles
532k12810691594
edited Mar 3 '12 at 23:38
Gilles
532k12810691594
edited Mar 3 '12 at 23:38
Gilles
532k12810691594
532k12810691594
asked Mar 3 '12 at 18:36
netbrainnetbrain
5131510
asked Mar 3 '12 at 18:36
netbrainnetbrain
5131510
asked Mar 3 '12 at 18:36
netbrainnetbrain
5131510
5131510
Solved in bash 4.4+
– Isaac
Nov 23 '18 at 1:18
add a comment |
Solved in bash 4.4+
– Isaac
Nov 23 '18 at 1:18
Solved in bash 4.4+
– Isaac
Nov 23 '18 at 1:18
Solved in bash 4.4+
– Isaac
Nov 23 '18 at 1:18
add a comment |
7 Answers
7
active
oldest
votes
The exclamation mark is part of history expansion in bash. To use it you need it enclosed in single quotes (eg: 'http://example.org/!132') or to directly escape it with a backslash () before the character (eg: "http://example.org/!132").
Note that in double quotes, a backslash before the exclam prevents history expansion, BUT the backslash is not removed in such a case. So it's better to use single quotes, so you're not passing a literal backslash to curl as part of the URL.
edited Jan 16 '18 at 4:58
Wildcard
22.7k963164
answered Mar 3 '12 at 18:38
Daniel PittmanDaniel Pittman
5,40912217
7
"http://example.org/!132"actually expands without interpreting the backslash (POSIX compliance reasons, I believe).
– Chris Down
Mar 3 '12 at 19:14
@ChrisDown, I tried to clarify that was my second option in the text. Thanks for pointing out the potential for confusion.
– Daniel Pittman
Mar 3 '12 at 22:30
5
For the record: It's not portable to try escaping "!". The best-practices recommendation is to always quote (singe-quotes) "!". Related: "^" (caret), is a non-metacharacter that needs quoting for portability. Finally, "!" should not be used in an if statement; use it as an argument to test instead if possible (again because of Solaris /bin/sh).
– Nicholas Wilson
Oct 18 '12 at 10:31
4
Only single quotes worked for me. zsh was still interpreting!and double quotes.
– orkoden
May 21 '14 at 16:29
1
On Solaris (rubbish old pre-XPG4 shell), '^' is an alias for|and is used to create a pipe. If you're sending scripts to customers and can't be sure what shell they'll run it in, you have to test with them all!
– Nicholas Wilson
Jan 16 '18 at 9:47
|
show 2 more comments
As well as the answer given by Daniel, you can also simply turn off history expansion altogether if you don't use it with set +H.
answered Mar 3 '12 at 19:15
Chris DownChris Down
79.8k14189202
16
Turning off history expansion altogether is the best advice I've heard all day! History expansion is dangerous and byzantine when there are much better alternatives (incremental history search withCtrl-R) that let you preview & edit your command so you don't blindly fire away with command!-14that you though was at!-12that, oops, happened to berm -rf *. Be safe. Disable history expansion! Eschew the!!
– aculich
Mar 6 '12 at 1:09
5
Biggest answer: history expansion is a huge security risk! It can be used to attack your Unix through a crafted URL.
– daniel Azuelos
Jun 15 '15 at 7:30
@aculich, or just use the POSIX-specified commandfc -14instead. But it's true that you can do that without history expansion being enabled also. Personally, I use!$and!viandsudo !!and evengit add !vi:$often enough to warrant leaving history expansion enabled.
– Wildcard
Jan 16 '18 at 5:02
add a comment |
I would personally do single quotes, but for completeness, I will also note since it is a URL, you can encode the ! as %21, e.g. curl -v http://example.org/%21132 .
answered Mar 3 '12 at 23:17
Aaron D. MarascoAaron D. Marasco
3,6381422
add a comment |
This also can do
curl -v "http://example.org/"'!'"287s87asdjh2/somepath/someresource"
orcurl -v "http://example.org/"!"287s87asdjh2/somepath/someresource"
Which works because bash concatenates adjacent strings. This approach is particularly useful when you have other things that need shell expansion, so you can't use single quotes for the entire string:
curl -v 'http://example.org/!'"287s87asdjh2/${basepath}/someresource"
! character is used for history expansions in command line prompt.
so this can be a problem in prompt but not in shell script files.
as you can see history expansions work even in double quotes.
edited 15 mins ago
pavon
1455
answered Jun 15 '15 at 6:43
mug896mug896
532410
There are lots of ways of making Unix commands and English sentences use more characters than they need to, and be more confusing than they need to be. How is this superior to the first / accepted / highest-voted answer, namely, putting the entire URL into single quotes?
– G-Man
Jun 15 '15 at 7:10
2
@G-Man : It tells another way to construct bash arguments. I wasn't aware of this method. Nothing wrong in learning new stuff.
– Sahil Singh
Jul 6 '16 at 12:30
@SahilSingh How is this new? It concatenates three strings, two enclosed in double quotes and one enclosed in single quotes. There is no nesting here.
– Raphael
Mar 10 '17 at 6:44
@G-Man It is not obvious that when you put 2 strings next to each other they get concatenated. printf("hello""world") would work in c as well, but printf("hello"'w') won't work, so you see knowing that bash accommodates such expressions was new to me, but I do agree from utility point of view, this is not superior. I liked the answer, so did Mark Shust.
– Sahil Singh
Mar 10 '17 at 7:06
2
@G-Man It's also useful when there are other string expansions one does want to happen in the same string. This is an easy way of separating two types of quoting behavior.
– WAF
May 1 '17 at 15:09
|
show 5 more comments
I have come across the same problem, and my simple solution was to use a variable:
E=!
curl -v "http://example.org/${E}287s87asdjh2/somepath/someresource"
Here the simplicity is that (1) It is portable across shells and commands (2) Does not require knowing escape syntax and ASCII codes.
answered May 25 '15 at 7:06
PremPrem
1,49621229
add a comment |
Ever since Bash 4.3, you can now use double quotes to quote the history expansion character:
$ bash --version
GNU bash, version 4.3...
[...]
$ echo "Hello World!"
Hello World!
answered Sep 16 '16 at 12:17
FlimmFlimm
1,39541828
this doesnt work outside ofecho, echo seems to handle this differently on its own
– Blauhirn
Sep 30 '17 at 12:04
@Blauhirn This has nothing to do with echo, and everything to do with quoting and the version of bash that you're running.
– Flimm
Oct 1 '17 at 13:38
1
This answer is wrong and should be deleted. Yourbashversion has nothing to do with the bang not being expanded, it's due to the fact that in your example the!is followed by "end of line" and that prevents the shell from trying to expand it. Tryecho "!Hello World"and you will see thatbashwill reply withbash: !Hello: event not found. See manual for more details
– don_crissti
Dec 19 '17 at 16:47
add a comment |
To those who are using git bash in windows, the accepted answer from @DanielPittman works. However, you should replace the backslash () with a forward slash (/).
For example, in unix, it'd look something like this:
curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS!ZR412543s'
For windows, it'd be something like this (focus on the forward slash in the authorization header part)
curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS/!ZR412543s'
answered Jan 16 '18 at 4:01
SamuelDevSamuelDev
1011
This doesn't make much sense. You have the argument single quoted, so regardless of the slashes involved the exclam won't result in history expansion.
– Wildcard
Jan 16 '18 at 5:03
Ohh you're right. I only posted this answer because when I was using Daniel's answer (using backslash), an error pops up.
– SamuelDev
Jan 16 '18 at 5:12
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%2f33339%2fcant-use-exclamation-mark-in-bash%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
The exclamation mark is part of history expansion in bash. To use it you need it enclosed in single quotes (eg: 'http://example.org/!132') or to directly escape it with a backslash () before the character (eg: "http://example.org/!132").
Note that in double quotes, a backslash before the exclam prevents history expansion, BUT the backslash is not removed in such a case. So it's better to use single quotes, so you're not passing a literal backslash to curl as part of the URL.
edited Jan 16 '18 at 4:58
Wildcard
22.7k963164
answered Mar 3 '12 at 18:38
Daniel PittmanDaniel Pittman
5,40912217
7
"http://example.org/!132"actually expands without interpreting the backslash (POSIX compliance reasons, I believe).
– Chris Down
Mar 3 '12 at 19:14
@ChrisDown, I tried to clarify that was my second option in the text. Thanks for pointing out the potential for confusion.
– Daniel Pittman
Mar 3 '12 at 22:30
5
For the record: It's not portable to try escaping "!". The best-practices recommendation is to always quote (singe-quotes) "!". Related: "^" (caret), is a non-metacharacter that needs quoting for portability. Finally, "!" should not be used in an if statement; use it as an argument to test instead if possible (again because of Solaris /bin/sh).
– Nicholas Wilson
Oct 18 '12 at 10:31
4
Only single quotes worked for me. zsh was still interpreting!and double quotes.
– orkoden
May 21 '14 at 16:29
1
On Solaris (rubbish old pre-XPG4 shell), '^' is an alias for|and is used to create a pipe. If you're sending scripts to customers and can't be sure what shell they'll run it in, you have to test with them all!
– Nicholas Wilson
Jan 16 '18 at 9:47
|
show 2 more comments
The exclamation mark is part of history expansion in bash. To use it you need it enclosed in single quotes (eg: 'http://example.org/!132') or to directly escape it with a backslash () before the character (eg: "http://example.org/!132").
Note that in double quotes, a backslash before the exclam prevents history expansion, BUT the backslash is not removed in such a case. So it's better to use single quotes, so you're not passing a literal backslash to curl as part of the URL.
edited Jan 16 '18 at 4:58
Wildcard
22.7k963164
answered Mar 3 '12 at 18:38
Daniel PittmanDaniel Pittman
5,40912217
7
"http://example.org/!132"actually expands without interpreting the backslash (POSIX compliance reasons, I believe).
– Chris Down
Mar 3 '12 at 19:14
@ChrisDown, I tried to clarify that was my second option in the text. Thanks for pointing out the potential for confusion.
– Daniel Pittman
Mar 3 '12 at 22:30
5
For the record: It's not portable to try escaping "!". The best-practices recommendation is to always quote (singe-quotes) "!". Related: "^" (caret), is a non-metacharacter that needs quoting for portability. Finally, "!" should not be used in an if statement; use it as an argument to test instead if possible (again because of Solaris /bin/sh).
– Nicholas Wilson
Oct 18 '12 at 10:31
4
Only single quotes worked for me. zsh was still interpreting!and double quotes.
– orkoden
May 21 '14 at 16:29
1
On Solaris (rubbish old pre-XPG4 shell), '^' is an alias for|and is used to create a pipe. If you're sending scripts to customers and can't be sure what shell they'll run it in, you have to test with them all!
– Nicholas Wilson
Jan 16 '18 at 9:47
|
show 2 more comments
The exclamation mark is part of history expansion in bash. To use it you need it enclosed in single quotes (eg: 'http://example.org/!132') or to directly escape it with a backslash () before the character (eg: "http://example.org/!132").
Note that in double quotes, a backslash before the exclam prevents history expansion, BUT the backslash is not removed in such a case. So it's better to use single quotes, so you're not passing a literal backslash to curl as part of the URL.
edited Jan 16 '18 at 4:58
Wildcard
22.7k963164
answered Mar 3 '12 at 18:38
Daniel PittmanDaniel Pittman
5,40912217
The exclamation mark is part of history expansion in bash. To use it you need it enclosed in single quotes (eg: 'http://example.org/!132') or to directly escape it with a backslash () before the character (eg: "http://example.org/!132").
Note that in double quotes, a backslash before the exclam prevents history expansion, BUT the backslash is not removed in such a case. So it's better to use single quotes, so you're not passing a literal backslash to curl as part of the URL.
edited Jan 16 '18 at 4:58
Wildcard
22.7k963164
answered Mar 3 '12 at 18:38
Daniel PittmanDaniel Pittman
5,40912217
edited Jan 16 '18 at 4:58
Wildcard
22.7k963164
edited Jan 16 '18 at 4:58
Wildcard
22.7k963164
edited Jan 16 '18 at 4:58
Wildcard
22.7k963164
22.7k963164
answered Mar 3 '12 at 18:38
Daniel PittmanDaniel Pittman
5,40912217
answered Mar 3 '12 at 18:38
Daniel PittmanDaniel Pittman
5,40912217
answered Mar 3 '12 at 18:38
Daniel PittmanDaniel Pittman
5,40912217
5,40912217
7
"http://example.org/!132"actually expands without interpreting the backslash (POSIX compliance reasons, I believe).
– Chris Down
Mar 3 '12 at 19:14
@ChrisDown, I tried to clarify that was my second option in the text. Thanks for pointing out the potential for confusion.
– Daniel Pittman
Mar 3 '12 at 22:30
5
For the record: It's not portable to try escaping "!". The best-practices recommendation is to always quote (singe-quotes) "!". Related: "^" (caret), is a non-metacharacter that needs quoting for portability. Finally, "!" should not be used in an if statement; use it as an argument to test instead if possible (again because of Solaris /bin/sh).
– Nicholas Wilson
Oct 18 '12 at 10:31
4
Only single quotes worked for me. zsh was still interpreting!and double quotes.
– orkoden
May 21 '14 at 16:29
1
On Solaris (rubbish old pre-XPG4 shell), '^' is an alias for|and is used to create a pipe. If you're sending scripts to customers and can't be sure what shell they'll run it in, you have to test with them all!
– Nicholas Wilson
Jan 16 '18 at 9:47
|
show 2 more comments
7
"http://example.org/!132"actually expands without interpreting the backslash (POSIX compliance reasons, I believe).
– Chris Down
Mar 3 '12 at 19:14
@ChrisDown, I tried to clarify that was my second option in the text. Thanks for pointing out the potential for confusion.
– Daniel Pittman
Mar 3 '12 at 22:30
5
For the record: It's not portable to try escaping "!". The best-practices recommendation is to always quote (singe-quotes) "!". Related: "^" (caret), is a non-metacharacter that needs quoting for portability. Finally, "!" should not be used in an if statement; use it as an argument to test instead if possible (again because of Solaris /bin/sh).
– Nicholas Wilson
Oct 18 '12 at 10:31
4
Only single quotes worked for me. zsh was still interpreting!and double quotes.
– orkoden
May 21 '14 at 16:29
1
On Solaris (rubbish old pre-XPG4 shell), '^' is an alias for|and is used to create a pipe. If you're sending scripts to customers and can't be sure what shell they'll run it in, you have to test with them all!
– Nicholas Wilson
Jan 16 '18 at 9:47
7
7
"http://example.org/!132" actually expands without interpreting the backslash (POSIX compliance reasons, I believe).– Chris Down
Mar 3 '12 at 19:14
"http://example.org/!132" actually expands without interpreting the backslash (POSIX compliance reasons, I believe).– Chris Down
Mar 3 '12 at 19:14
@ChrisDown, I tried to clarify that was my second option in the text. Thanks for pointing out the potential for confusion.
– Daniel Pittman
Mar 3 '12 at 22:30
@ChrisDown, I tried to clarify that was my second option in the text. Thanks for pointing out the potential for confusion.
– Daniel Pittman
Mar 3 '12 at 22:30
5
5
For the record: It's not portable to try escaping "!". The best-practices recommendation is to always quote (singe-quotes) "!". Related: "^" (caret), is a non-metacharacter that needs quoting for portability. Finally, "!" should not be used in an if statement; use it as an argument to test instead if possible (again because of Solaris /bin/sh).
– Nicholas Wilson
Oct 18 '12 at 10:31
For the record: It's not portable to try escaping "!". The best-practices recommendation is to always quote (singe-quotes) "!". Related: "^" (caret), is a non-metacharacter that needs quoting for portability. Finally, "!" should not be used in an if statement; use it as an argument to test instead if possible (again because of Solaris /bin/sh).
– Nicholas Wilson
Oct 18 '12 at 10:31
4
4
Only single quotes worked for me. zsh was still interpreting
! and double quotes.– orkoden
May 21 '14 at 16:29
Only single quotes worked for me. zsh was still interpreting
! and double quotes.– orkoden
May 21 '14 at 16:29
1
1
On Solaris (rubbish old pre-XPG4 shell), '^' is an alias for
| and is used to create a pipe. If you're sending scripts to customers and can't be sure what shell they'll run it in, you have to test with them all!– Nicholas Wilson
Jan 16 '18 at 9:47
On Solaris (rubbish old pre-XPG4 shell), '^' is an alias for
| and is used to create a pipe. If you're sending scripts to customers and can't be sure what shell they'll run it in, you have to test with them all!– Nicholas Wilson
Jan 16 '18 at 9:47
|
show 2 more comments
As well as the answer given by Daniel, you can also simply turn off history expansion altogether if you don't use it with set +H.
answered Mar 3 '12 at 19:15
Chris DownChris Down
79.8k14189202
16
Turning off history expansion altogether is the best advice I've heard all day! History expansion is dangerous and byzantine when there are much better alternatives (incremental history search withCtrl-R) that let you preview & edit your command so you don't blindly fire away with command!-14that you though was at!-12that, oops, happened to berm -rf *. Be safe. Disable history expansion! Eschew the!!
– aculich
Mar 6 '12 at 1:09
5
Biggest answer: history expansion is a huge security risk! It can be used to attack your Unix through a crafted URL.
– daniel Azuelos
Jun 15 '15 at 7:30
@aculich, or just use the POSIX-specified commandfc -14instead. But it's true that you can do that without history expansion being enabled also. Personally, I use!$and!viandsudo !!and evengit add !vi:$often enough to warrant leaving history expansion enabled.
– Wildcard
Jan 16 '18 at 5:02
add a comment |
As well as the answer given by Daniel, you can also simply turn off history expansion altogether if you don't use it with set +H.
answered Mar 3 '12 at 19:15
Chris DownChris Down
79.8k14189202
16
Turning off history expansion altogether is the best advice I've heard all day! History expansion is dangerous and byzantine when there are much better alternatives (incremental history search withCtrl-R) that let you preview & edit your command so you don't blindly fire away with command!-14that you though was at!-12that, oops, happened to berm -rf *. Be safe. Disable history expansion! Eschew the!!
– aculich
Mar 6 '12 at 1:09
5
Biggest answer: history expansion is a huge security risk! It can be used to attack your Unix through a crafted URL.
– daniel Azuelos
Jun 15 '15 at 7:30
@aculich, or just use the POSIX-specified commandfc -14instead. But it's true that you can do that without history expansion being enabled also. Personally, I use!$and!viandsudo !!and evengit add !vi:$often enough to warrant leaving history expansion enabled.
– Wildcard
Jan 16 '18 at 5:02
add a comment |
As well as the answer given by Daniel, you can also simply turn off history expansion altogether if you don't use it with set +H.
answered Mar 3 '12 at 19:15
Chris DownChris Down
79.8k14189202
As well as the answer given by Daniel, you can also simply turn off history expansion altogether if you don't use it with set +H.
answered Mar 3 '12 at 19:15
Chris DownChris Down
79.8k14189202
answered Mar 3 '12 at 19:15
Chris DownChris Down
79.8k14189202
answered Mar 3 '12 at 19:15
Chris DownChris Down
79.8k14189202
answered Mar 3 '12 at 19:15
Chris DownChris Down
79.8k14189202
79.8k14189202
16
Turning off history expansion altogether is the best advice I've heard all day! History expansion is dangerous and byzantine when there are much better alternatives (incremental history search withCtrl-R) that let you preview & edit your command so you don't blindly fire away with command!-14that you though was at!-12that, oops, happened to berm -rf *. Be safe. Disable history expansion! Eschew the!!
– aculich
Mar 6 '12 at 1:09
5
Biggest answer: history expansion is a huge security risk! It can be used to attack your Unix through a crafted URL.
– daniel Azuelos
Jun 15 '15 at 7:30
@aculich, or just use the POSIX-specified commandfc -14instead. But it's true that you can do that without history expansion being enabled also. Personally, I use!$and!viandsudo !!and evengit add !vi:$often enough to warrant leaving history expansion enabled.
– Wildcard
Jan 16 '18 at 5:02
add a comment |
16
Turning off history expansion altogether is the best advice I've heard all day! History expansion is dangerous and byzantine when there are much better alternatives (incremental history search withCtrl-R) that let you preview & edit your command so you don't blindly fire away with command!-14that you though was at!-12that, oops, happened to berm -rf *. Be safe. Disable history expansion! Eschew the!!
– aculich
Mar 6 '12 at 1:09
5
Biggest answer: history expansion is a huge security risk! It can be used to attack your Unix through a crafted URL.
– daniel Azuelos
Jun 15 '15 at 7:30
@aculich, or just use the POSIX-specified commandfc -14instead. But it's true that you can do that without history expansion being enabled also. Personally, I use!$and!viandsudo !!and evengit add !vi:$often enough to warrant leaving history expansion enabled.
– Wildcard
Jan 16 '18 at 5:02
16
16
Turning off history expansion altogether is the best advice I've heard all day! History expansion is dangerous and byzantine when there are much better alternatives (incremental history search with
Ctrl-R) that let you preview & edit your command so you don't blindly fire away with command !-14 that you though was at !-12 that, oops, happened to be rm -rf *. Be safe. Disable history expansion! Eschew the !!– aculich
Mar 6 '12 at 1:09
Turning off history expansion altogether is the best advice I've heard all day! History expansion is dangerous and byzantine when there are much better alternatives (incremental history search with
Ctrl-R) that let you preview & edit your command so you don't blindly fire away with command !-14 that you though was at !-12 that, oops, happened to be rm -rf *. Be safe. Disable history expansion! Eschew the !!– aculich
Mar 6 '12 at 1:09
5
5
Biggest answer: history expansion is a huge security risk! It can be used to attack your Unix through a crafted URL.
– daniel Azuelos
Jun 15 '15 at 7:30
Biggest answer: history expansion is a huge security risk! It can be used to attack your Unix through a crafted URL.
– daniel Azuelos
Jun 15 '15 at 7:30
@aculich, or just use the POSIX-specified command
fc -14 instead. But it's true that you can do that without history expansion being enabled also. Personally, I use !$ and !vi and sudo !! and even git add !vi:$ often enough to warrant leaving history expansion enabled.– Wildcard
Jan 16 '18 at 5:02
@aculich, or just use the POSIX-specified command
fc -14 instead. But it's true that you can do that without history expansion being enabled also. Personally, I use !$ and !vi and sudo !! and even git add !vi:$ often enough to warrant leaving history expansion enabled.– Wildcard
Jan 16 '18 at 5:02
add a comment |
I would personally do single quotes, but for completeness, I will also note since it is a URL, you can encode the ! as %21, e.g. curl -v http://example.org/%21132 .
answered Mar 3 '12 at 23:17
Aaron D. MarascoAaron D. Marasco
3,6381422
add a comment |
I would personally do single quotes, but for completeness, I will also note since it is a URL, you can encode the ! as %21, e.g. curl -v http://example.org/%21132 .
answered Mar 3 '12 at 23:17
Aaron D. MarascoAaron D. Marasco
3,6381422
add a comment |
I would personally do single quotes, but for completeness, I will also note since it is a URL, you can encode the ! as %21, e.g. curl -v http://example.org/%21132 .
answered Mar 3 '12 at 23:17
Aaron D. MarascoAaron D. Marasco
3,6381422
I would personally do single quotes, but for completeness, I will also note since it is a URL, you can encode the ! as %21, e.g. curl -v http://example.org/%21132 .
answered Mar 3 '12 at 23:17
Aaron D. MarascoAaron D. Marasco
3,6381422
answered Mar 3 '12 at 23:17
Aaron D. MarascoAaron D. Marasco
3,6381422
answered Mar 3 '12 at 23:17
Aaron D. MarascoAaron D. Marasco
3,6381422
answered Mar 3 '12 at 23:17
Aaron D. MarascoAaron D. Marasco
3,6381422
3,6381422
add a comment |
add a comment |
This also can do
curl -v "http://example.org/"'!'"287s87asdjh2/somepath/someresource"
orcurl -v "http://example.org/"!"287s87asdjh2/somepath/someresource"
Which works because bash concatenates adjacent strings. This approach is particularly useful when you have other things that need shell expansion, so you can't use single quotes for the entire string:
curl -v 'http://example.org/!'"287s87asdjh2/${basepath}/someresource"
! character is used for history expansions in command line prompt.
so this can be a problem in prompt but not in shell script files.
as you can see history expansions work even in double quotes.
edited 15 mins ago
pavon
1455
answered Jun 15 '15 at 6:43
mug896mug896
532410
There are lots of ways of making Unix commands and English sentences use more characters than they need to, and be more confusing than they need to be. How is this superior to the first / accepted / highest-voted answer, namely, putting the entire URL into single quotes?
– G-Man
Jun 15 '15 at 7:10
2
@G-Man : It tells another way to construct bash arguments. I wasn't aware of this method. Nothing wrong in learning new stuff.
– Sahil Singh
Jul 6 '16 at 12:30
@SahilSingh How is this new? It concatenates three strings, two enclosed in double quotes and one enclosed in single quotes. There is no nesting here.
– Raphael
Mar 10 '17 at 6:44
@G-Man It is not obvious that when you put 2 strings next to each other they get concatenated. printf("hello""world") would work in c as well, but printf("hello"'w') won't work, so you see knowing that bash accommodates such expressions was new to me, but I do agree from utility point of view, this is not superior. I liked the answer, so did Mark Shust.
– Sahil Singh
Mar 10 '17 at 7:06
2
@G-Man It's also useful when there are other string expansions one does want to happen in the same string. This is an easy way of separating two types of quoting behavior.
– WAF
May 1 '17 at 15:09
|
show 5 more comments
This also can do
curl -v "http://example.org/"'!'"287s87asdjh2/somepath/someresource"
orcurl -v "http://example.org/"!"287s87asdjh2/somepath/someresource"
Which works because bash concatenates adjacent strings. This approach is particularly useful when you have other things that need shell expansion, so you can't use single quotes for the entire string:
curl -v 'http://example.org/!'"287s87asdjh2/${basepath}/someresource"
! character is used for history expansions in command line prompt.
so this can be a problem in prompt but not in shell script files.
as you can see history expansions work even in double quotes.
edited 15 mins ago
pavon
1455
answered Jun 15 '15 at 6:43
mug896mug896
532410
There are lots of ways of making Unix commands and English sentences use more characters than they need to, and be more confusing than they need to be. How is this superior to the first / accepted / highest-voted answer, namely, putting the entire URL into single quotes?
– G-Man
Jun 15 '15 at 7:10
2
@G-Man : It tells another way to construct bash arguments. I wasn't aware of this method. Nothing wrong in learning new stuff.
– Sahil Singh
Jul 6 '16 at 12:30
@SahilSingh How is this new? It concatenates three strings, two enclosed in double quotes and one enclosed in single quotes. There is no nesting here.
– Raphael
Mar 10 '17 at 6:44
@G-Man It is not obvious that when you put 2 strings next to each other they get concatenated. printf("hello""world") would work in c as well, but printf("hello"'w') won't work, so you see knowing that bash accommodates such expressions was new to me, but I do agree from utility point of view, this is not superior. I liked the answer, so did Mark Shust.
– Sahil Singh
Mar 10 '17 at 7:06
2
@G-Man It's also useful when there are other string expansions one does want to happen in the same string. This is an easy way of separating two types of quoting behavior.
– WAF
May 1 '17 at 15:09
|
show 5 more comments
This also can do
curl -v "http://example.org/"'!'"287s87asdjh2/somepath/someresource"
orcurl -v "http://example.org/"!"287s87asdjh2/somepath/someresource"
Which works because bash concatenates adjacent strings. This approach is particularly useful when you have other things that need shell expansion, so you can't use single quotes for the entire string:
curl -v 'http://example.org/!'"287s87asdjh2/${basepath}/someresource"
! character is used for history expansions in command line prompt.
so this can be a problem in prompt but not in shell script files.
as you can see history expansions work even in double quotes.
edited 15 mins ago
pavon
1455
answered Jun 15 '15 at 6:43
mug896mug896
532410
This also can do
curl -v "http://example.org/"'!'"287s87asdjh2/somepath/someresource"
orcurl -v "http://example.org/"!"287s87asdjh2/somepath/someresource"
Which works because bash concatenates adjacent strings. This approach is particularly useful when you have other things that need shell expansion, so you can't use single quotes for the entire string:
curl -v 'http://example.org/!'"287s87asdjh2/${basepath}/someresource"
! character is used for history expansions in command line prompt.
so this can be a problem in prompt but not in shell script files.
as you can see history expansions work even in double quotes.
edited 15 mins ago
pavon
1455
answered Jun 15 '15 at 6:43
mug896mug896
532410
edited 15 mins ago
pavon
1455
edited 15 mins ago
pavon
1455
edited 15 mins ago
pavon
1455
1455
answered Jun 15 '15 at 6:43
mug896mug896
532410
answered Jun 15 '15 at 6:43
mug896mug896
532410
answered Jun 15 '15 at 6:43
mug896mug896
532410
532410
There are lots of ways of making Unix commands and English sentences use more characters than they need to, and be more confusing than they need to be. How is this superior to the first / accepted / highest-voted answer, namely, putting the entire URL into single quotes?
– G-Man
Jun 15 '15 at 7:10
2
@G-Man : It tells another way to construct bash arguments. I wasn't aware of this method. Nothing wrong in learning new stuff.
– Sahil Singh
Jul 6 '16 at 12:30
@SahilSingh How is this new? It concatenates three strings, two enclosed in double quotes and one enclosed in single quotes. There is no nesting here.
– Raphael
Mar 10 '17 at 6:44
@G-Man It is not obvious that when you put 2 strings next to each other they get concatenated. printf("hello""world") would work in c as well, but printf("hello"'w') won't work, so you see knowing that bash accommodates such expressions was new to me, but I do agree from utility point of view, this is not superior. I liked the answer, so did Mark Shust.
– Sahil Singh
Mar 10 '17 at 7:06
2
@G-Man It's also useful when there are other string expansions one does want to happen in the same string. This is an easy way of separating two types of quoting behavior.
– WAF
May 1 '17 at 15:09
|
show 5 more comments
There are lots of ways of making Unix commands and English sentences use more characters than they need to, and be more confusing than they need to be. How is this superior to the first / accepted / highest-voted answer, namely, putting the entire URL into single quotes?
– G-Man
Jun 15 '15 at 7:10
2
@G-Man : It tells another way to construct bash arguments. I wasn't aware of this method. Nothing wrong in learning new stuff.
– Sahil Singh
Jul 6 '16 at 12:30
@SahilSingh How is this new? It concatenates three strings, two enclosed in double quotes and one enclosed in single quotes. There is no nesting here.
– Raphael
Mar 10 '17 at 6:44
@G-Man It is not obvious that when you put 2 strings next to each other they get concatenated. printf("hello""world") would work in c as well, but printf("hello"'w') won't work, so you see knowing that bash accommodates such expressions was new to me, but I do agree from utility point of view, this is not superior. I liked the answer, so did Mark Shust.
– Sahil Singh
Mar 10 '17 at 7:06
2
@G-Man It's also useful when there are other string expansions one does want to happen in the same string. This is an easy way of separating two types of quoting behavior.
– WAF
May 1 '17 at 15:09
There are lots of ways of making Unix commands and English sentences use more characters than they need to, and be more confusing than they need to be. How is this superior to the first / accepted / highest-voted answer, namely, putting the entire URL into single quotes?
– G-Man
Jun 15 '15 at 7:10
There are lots of ways of making Unix commands and English sentences use more characters than they need to, and be more confusing than they need to be. How is this superior to the first / accepted / highest-voted answer, namely, putting the entire URL into single quotes?
– G-Man
Jun 15 '15 at 7:10
2
2
@G-Man : It tells another way to construct bash arguments. I wasn't aware of this method. Nothing wrong in learning new stuff.
– Sahil Singh
Jul 6 '16 at 12:30
@G-Man : It tells another way to construct bash arguments. I wasn't aware of this method. Nothing wrong in learning new stuff.
– Sahil Singh
Jul 6 '16 at 12:30
@SahilSingh How is this new? It concatenates three strings, two enclosed in double quotes and one enclosed in single quotes. There is no nesting here.
– Raphael
Mar 10 '17 at 6:44
@SahilSingh How is this new? It concatenates three strings, two enclosed in double quotes and one enclosed in single quotes. There is no nesting here.
– Raphael
Mar 10 '17 at 6:44
@G-Man It is not obvious that when you put 2 strings next to each other they get concatenated. printf("hello""world") would work in c as well, but printf("hello"'w') won't work, so you see knowing that bash accommodates such expressions was new to me, but I do agree from utility point of view, this is not superior. I liked the answer, so did Mark Shust.
– Sahil Singh
Mar 10 '17 at 7:06
@G-Man It is not obvious that when you put 2 strings next to each other they get concatenated. printf("hello""world") would work in c as well, but printf("hello"'w') won't work, so you see knowing that bash accommodates such expressions was new to me, but I do agree from utility point of view, this is not superior. I liked the answer, so did Mark Shust.
– Sahil Singh
Mar 10 '17 at 7:06
2
2
@G-Man It's also useful when there are other string expansions one does want to happen in the same string. This is an easy way of separating two types of quoting behavior.
– WAF
May 1 '17 at 15:09
@G-Man It's also useful when there are other string expansions one does want to happen in the same string. This is an easy way of separating two types of quoting behavior.
– WAF
May 1 '17 at 15:09
|
show 5 more comments
I have come across the same problem, and my simple solution was to use a variable:
E=!
curl -v "http://example.org/${E}287s87asdjh2/somepath/someresource"
Here the simplicity is that (1) It is portable across shells and commands (2) Does not require knowing escape syntax and ASCII codes.
answered May 25 '15 at 7:06
PremPrem
1,49621229
add a comment |
I have come across the same problem, and my simple solution was to use a variable:
E=!
curl -v "http://example.org/${E}287s87asdjh2/somepath/someresource"
Here the simplicity is that (1) It is portable across shells and commands (2) Does not require knowing escape syntax and ASCII codes.
answered May 25 '15 at 7:06
PremPrem
1,49621229
add a comment |
I have come across the same problem, and my simple solution was to use a variable:
E=!
curl -v "http://example.org/${E}287s87asdjh2/somepath/someresource"
Here the simplicity is that (1) It is portable across shells and commands (2) Does not require knowing escape syntax and ASCII codes.
answered May 25 '15 at 7:06
PremPrem
1,49621229
I have come across the same problem, and my simple solution was to use a variable:
E=!
curl -v "http://example.org/${E}287s87asdjh2/somepath/someresource"
Here the simplicity is that (1) It is portable across shells and commands (2) Does not require knowing escape syntax and ASCII codes.
answered May 25 '15 at 7:06
PremPrem
1,49621229
answered May 25 '15 at 7:06
PremPrem
1,49621229
answered May 25 '15 at 7:06
PremPrem
1,49621229
answered May 25 '15 at 7:06
PremPrem
1,49621229
1,49621229
add a comment |
add a comment |
Ever since Bash 4.3, you can now use double quotes to quote the history expansion character:
$ bash --version
GNU bash, version 4.3...
[...]
$ echo "Hello World!"
Hello World!
answered Sep 16 '16 at 12:17
FlimmFlimm
1,39541828
this doesnt work outside ofecho, echo seems to handle this differently on its own
– Blauhirn
Sep 30 '17 at 12:04
@Blauhirn This has nothing to do with echo, and everything to do with quoting and the version of bash that you're running.
– Flimm
Oct 1 '17 at 13:38
1
This answer is wrong and should be deleted. Yourbashversion has nothing to do with the bang not being expanded, it's due to the fact that in your example the!is followed by "end of line" and that prevents the shell from trying to expand it. Tryecho "!Hello World"and you will see thatbashwill reply withbash: !Hello: event not found. See manual for more details
– don_crissti
Dec 19 '17 at 16:47
add a comment |
Ever since Bash 4.3, you can now use double quotes to quote the history expansion character:
$ bash --version
GNU bash, version 4.3...
[...]
$ echo "Hello World!"
Hello World!
answered Sep 16 '16 at 12:17
FlimmFlimm
1,39541828
this doesnt work outside ofecho, echo seems to handle this differently on its own
– Blauhirn
Sep 30 '17 at 12:04
@Blauhirn This has nothing to do with echo, and everything to do with quoting and the version of bash that you're running.
– Flimm
Oct 1 '17 at 13:38
1
This answer is wrong and should be deleted. Yourbashversion has nothing to do with the bang not being expanded, it's due to the fact that in your example the!is followed by "end of line" and that prevents the shell from trying to expand it. Tryecho "!Hello World"and you will see thatbashwill reply withbash: !Hello: event not found. See manual for more details
– don_crissti
Dec 19 '17 at 16:47
add a comment |
Ever since Bash 4.3, you can now use double quotes to quote the history expansion character:
$ bash --version
GNU bash, version 4.3...
[...]
$ echo "Hello World!"
Hello World!
answered Sep 16 '16 at 12:17
FlimmFlimm
1,39541828
Ever since Bash 4.3, you can now use double quotes to quote the history expansion character:
$ bash --version
GNU bash, version 4.3...
[...]
$ echo "Hello World!"
Hello World!
answered Sep 16 '16 at 12:17
FlimmFlimm
1,39541828
answered Sep 16 '16 at 12:17
FlimmFlimm
1,39541828
answered Sep 16 '16 at 12:17
FlimmFlimm
1,39541828
answered Sep 16 '16 at 12:17
FlimmFlimm
1,39541828
1,39541828
this doesnt work outside ofecho, echo seems to handle this differently on its own
– Blauhirn
Sep 30 '17 at 12:04
@Blauhirn This has nothing to do with echo, and everything to do with quoting and the version of bash that you're running.
– Flimm
Oct 1 '17 at 13:38
1
This answer is wrong and should be deleted. Yourbashversion has nothing to do with the bang not being expanded, it's due to the fact that in your example the!is followed by "end of line" and that prevents the shell from trying to expand it. Tryecho "!Hello World"and you will see thatbashwill reply withbash: !Hello: event not found. See manual for more details
– don_crissti
Dec 19 '17 at 16:47
add a comment |
this doesnt work outside ofecho, echo seems to handle this differently on its own
– Blauhirn
Sep 30 '17 at 12:04
@Blauhirn This has nothing to do with echo, and everything to do with quoting and the version of bash that you're running.
– Flimm
Oct 1 '17 at 13:38
1
This answer is wrong and should be deleted. Yourbashversion has nothing to do with the bang not being expanded, it's due to the fact that in your example the!is followed by "end of line" and that prevents the shell from trying to expand it. Tryecho "!Hello World"and you will see thatbashwill reply withbash: !Hello: event not found. See manual for more details
– don_crissti
Dec 19 '17 at 16:47
this doesnt work outside of
echo, echo seems to handle this differently on its own– Blauhirn
Sep 30 '17 at 12:04
this doesnt work outside of
echo, echo seems to handle this differently on its own– Blauhirn
Sep 30 '17 at 12:04
@Blauhirn This has nothing to do with echo, and everything to do with quoting and the version of bash that you're running.
– Flimm
Oct 1 '17 at 13:38
@Blauhirn This has nothing to do with echo, and everything to do with quoting and the version of bash that you're running.
– Flimm
Oct 1 '17 at 13:38
1
1
This answer is wrong and should be deleted. Your
bash version has nothing to do with the bang not being expanded, it's due to the fact that in your example the ! is followed by "end of line" and that prevents the shell from trying to expand it. Try echo "!Hello World" and you will see that bash will reply with bash: !Hello: event not found. See manual for more details– don_crissti
Dec 19 '17 at 16:47
This answer is wrong and should be deleted. Your
bash version has nothing to do with the bang not being expanded, it's due to the fact that in your example the ! is followed by "end of line" and that prevents the shell from trying to expand it. Try echo "!Hello World" and you will see that bash will reply with bash: !Hello: event not found. See manual for more details– don_crissti
Dec 19 '17 at 16:47
add a comment |
To those who are using git bash in windows, the accepted answer from @DanielPittman works. However, you should replace the backslash () with a forward slash (/).
For example, in unix, it'd look something like this:
curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS!ZR412543s'
For windows, it'd be something like this (focus on the forward slash in the authorization header part)
curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS/!ZR412543s'
answered Jan 16 '18 at 4:01
SamuelDevSamuelDev
1011
This doesn't make much sense. You have the argument single quoted, so regardless of the slashes involved the exclam won't result in history expansion.
– Wildcard
Jan 16 '18 at 5:03
Ohh you're right. I only posted this answer because when I was using Daniel's answer (using backslash), an error pops up.
– SamuelDev
Jan 16 '18 at 5:12
add a comment |
To those who are using git bash in windows, the accepted answer from @DanielPittman works. However, you should replace the backslash () with a forward slash (/).
For example, in unix, it'd look something like this:
curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS!ZR412543s'
For windows, it'd be something like this (focus on the forward slash in the authorization header part)
curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS/!ZR412543s'
answered Jan 16 '18 at 4:01
SamuelDevSamuelDev
1011
This doesn't make much sense. You have the argument single quoted, so regardless of the slashes involved the exclam won't result in history expansion.
– Wildcard
Jan 16 '18 at 5:03
Ohh you're right. I only posted this answer because when I was using Daniel's answer (using backslash), an error pops up.
– SamuelDev
Jan 16 '18 at 5:12
add a comment |
To those who are using git bash in windows, the accepted answer from @DanielPittman works. However, you should replace the backslash () with a forward slash (/).
For example, in unix, it'd look something like this:
curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS!ZR412543s'
For windows, it'd be something like this (focus on the forward slash in the authorization header part)
curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS/!ZR412543s'
answered Jan 16 '18 at 4:01
SamuelDevSamuelDev
1011
To those who are using git bash in windows, the accepted answer from @DanielPittman works. However, you should replace the backslash () with a forward slash (/).
For example, in unix, it'd look something like this:
curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS!ZR412543s'
For windows, it'd be something like this (focus on the forward slash in the authorization header part)
curl https://abc.com/services -H 'Authorization: Bearer 111A80BBZZCnS/!ZR412543s'
answered Jan 16 '18 at 4:01
SamuelDevSamuelDev
1011
answered Jan 16 '18 at 4:01
SamuelDevSamuelDev
1011
answered Jan 16 '18 at 4:01
SamuelDevSamuelDev
1011
answered Jan 16 '18 at 4:01
SamuelDevSamuelDev
1011
1011
This doesn't make much sense. You have the argument single quoted, so regardless of the slashes involved the exclam won't result in history expansion.
– Wildcard
Jan 16 '18 at 5:03
Ohh you're right. I only posted this answer because when I was using Daniel's answer (using backslash), an error pops up.
– SamuelDev
Jan 16 '18 at 5:12
add a comment |
This doesn't make much sense. You have the argument single quoted, so regardless of the slashes involved the exclam won't result in history expansion.
– Wildcard
Jan 16 '18 at 5:03
Ohh you're right. I only posted this answer because when I was using Daniel's answer (using backslash), an error pops up.
– SamuelDev
Jan 16 '18 at 5:12
This doesn't make much sense. You have the argument single quoted, so regardless of the slashes involved the exclam won't result in history expansion.
– Wildcard
Jan 16 '18 at 5:03
This doesn't make much sense. You have the argument single quoted, so regardless of the slashes involved the exclam won't result in history expansion.
– Wildcard
Jan 16 '18 at 5:03
Ohh you're right. I only posted this answer because when I was using Daniel's answer (using backslash), an error pops up.
– SamuelDev
Jan 16 '18 at 5:12
Ohh you're right. I only posted this answer because when I was using Daniel's answer (using backslash), an error pops up.
– SamuelDev
Jan 16 '18 at 5:12
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%2f33339%2fcant-use-exclamation-mark-in-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
Solved in bash 4.4+
– Isaac
Nov 23 '18 at 1:18