File globbing pattern, !(*example), behaves differently in bash script than it does in bash shell
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{
margin-bottom:0;
}
The following works when pasted directly into my bash terminal (I call bash explicitly, bash version: 4.4.19(1)-release (x86_64-pc-linux-gnu)
)
for filename in /home/dean/Downloads/!(*example).txt; do
echo "${filename}"
done
This command echoes back all of the txt files that do not have 'example' in the filename.
But when I convert this into a script called temp.sh
, chmod +x temp.sh
and call it by ./temp.sh
:
#!/usr/bin/env bash
for filename in /home/dean/Downloads/!(*example).txt; do
echo "${filename}"
done
I get the following error:
dean@dean-thinkpad-p52s:~/Downloads$ ./temp.sh
./temp.sh: line 3: syntax error near unexpected token `('
./temp.sh: line 3: `for filename in /home/dean/Downloads/!(*example).txt; do'
I fail to understand the problem here. Why is it doing exactly what I want in the shell but not in the script.
Edit (to answer panki's question):
The difference between when env
is called in shell/terminal and when env
is called in shell/script:
dean@dean-thinkpad-p52s:~/Downloads$ diff example_myshell.txt example_called_script.txt
5a6
> _=/usr/bin/env
36,37d36
< TERM=xterm-256color
< SHELL=/bin/bash
38a38,39
> SHELL=/bin/bash
> TERM=xterm-256color
45c46
< PYENV_SHELL=bash
---
> SHLVL=4
47c48
< SHLVL=3
---
> PYENV_SHELL=bash
61d61
< _=/usr/bin/env
bash shell-script wildcards bash-expansion
add a comment
|
The following works when pasted directly into my bash terminal (I call bash explicitly, bash version: 4.4.19(1)-release (x86_64-pc-linux-gnu)
)
for filename in /home/dean/Downloads/!(*example).txt; do
echo "${filename}"
done
This command echoes back all of the txt files that do not have 'example' in the filename.
But when I convert this into a script called temp.sh
, chmod +x temp.sh
and call it by ./temp.sh
:
#!/usr/bin/env bash
for filename in /home/dean/Downloads/!(*example).txt; do
echo "${filename}"
done
I get the following error:
dean@dean-thinkpad-p52s:~/Downloads$ ./temp.sh
./temp.sh: line 3: syntax error near unexpected token `('
./temp.sh: line 3: `for filename in /home/dean/Downloads/!(*example).txt; do'
I fail to understand the problem here. Why is it doing exactly what I want in the shell but not in the script.
Edit (to answer panki's question):
The difference between when env
is called in shell/terminal and when env
is called in shell/script:
dean@dean-thinkpad-p52s:~/Downloads$ diff example_myshell.txt example_called_script.txt
5a6
> _=/usr/bin/env
36,37d36
< TERM=xterm-256color
< SHELL=/bin/bash
38a38,39
> SHELL=/bin/bash
> TERM=xterm-256color
45c46
< PYENV_SHELL=bash
---
> SHLVL=4
47c48
< SHLVL=3
---
> PYENV_SHELL=bash
61d61
< _=/usr/bin/env
bash shell-script wildcards bash-expansion
Does it work if you source the script? Is the bash returned byenv
the same as your shell?
– Panki
May 27 at 9:56
Sourcing the script works, but I need it to work when calling the script. I don't know if I follow your second question but I have included the difference of whenenv
is called in script and when it is called in shell.
– Dean Kayton
May 27 at 10:03
add a comment
|
The following works when pasted directly into my bash terminal (I call bash explicitly, bash version: 4.4.19(1)-release (x86_64-pc-linux-gnu)
)
for filename in /home/dean/Downloads/!(*example).txt; do
echo "${filename}"
done
This command echoes back all of the txt files that do not have 'example' in the filename.
But when I convert this into a script called temp.sh
, chmod +x temp.sh
and call it by ./temp.sh
:
#!/usr/bin/env bash
for filename in /home/dean/Downloads/!(*example).txt; do
echo "${filename}"
done
I get the following error:
dean@dean-thinkpad-p52s:~/Downloads$ ./temp.sh
./temp.sh: line 3: syntax error near unexpected token `('
./temp.sh: line 3: `for filename in /home/dean/Downloads/!(*example).txt; do'
I fail to understand the problem here. Why is it doing exactly what I want in the shell but not in the script.
Edit (to answer panki's question):
The difference between when env
is called in shell/terminal and when env
is called in shell/script:
dean@dean-thinkpad-p52s:~/Downloads$ diff example_myshell.txt example_called_script.txt
5a6
> _=/usr/bin/env
36,37d36
< TERM=xterm-256color
< SHELL=/bin/bash
38a38,39
> SHELL=/bin/bash
> TERM=xterm-256color
45c46
< PYENV_SHELL=bash
---
> SHLVL=4
47c48
< SHLVL=3
---
> PYENV_SHELL=bash
61d61
< _=/usr/bin/env
bash shell-script wildcards bash-expansion
The following works when pasted directly into my bash terminal (I call bash explicitly, bash version: 4.4.19(1)-release (x86_64-pc-linux-gnu)
)
for filename in /home/dean/Downloads/!(*example).txt; do
echo "${filename}"
done
This command echoes back all of the txt files that do not have 'example' in the filename.
But when I convert this into a script called temp.sh
, chmod +x temp.sh
and call it by ./temp.sh
:
#!/usr/bin/env bash
for filename in /home/dean/Downloads/!(*example).txt; do
echo "${filename}"
done
I get the following error:
dean@dean-thinkpad-p52s:~/Downloads$ ./temp.sh
./temp.sh: line 3: syntax error near unexpected token `('
./temp.sh: line 3: `for filename in /home/dean/Downloads/!(*example).txt; do'
I fail to understand the problem here. Why is it doing exactly what I want in the shell but not in the script.
Edit (to answer panki's question):
The difference between when env
is called in shell/terminal and when env
is called in shell/script:
dean@dean-thinkpad-p52s:~/Downloads$ diff example_myshell.txt example_called_script.txt
5a6
> _=/usr/bin/env
36,37d36
< TERM=xterm-256color
< SHELL=/bin/bash
38a38,39
> SHELL=/bin/bash
> TERM=xterm-256color
45c46
< PYENV_SHELL=bash
---
> SHLVL=4
47c48
< SHLVL=3
---
> PYENV_SHELL=bash
61d61
< _=/usr/bin/env
bash shell-script wildcards bash-expansion
bash shell-script wildcards bash-expansion
edited May 27 at 10:04
Dean Kayton
asked May 27 at 9:53
Dean KaytonDean Kayton
535 bronze badges
535 bronze badges
Does it work if you source the script? Is the bash returned byenv
the same as your shell?
– Panki
May 27 at 9:56
Sourcing the script works, but I need it to work when calling the script. I don't know if I follow your second question but I have included the difference of whenenv
is called in script and when it is called in shell.
– Dean Kayton
May 27 at 10:03
add a comment
|
Does it work if you source the script? Is the bash returned byenv
the same as your shell?
– Panki
May 27 at 9:56
Sourcing the script works, but I need it to work when calling the script. I don't know if I follow your second question but I have included the difference of whenenv
is called in script and when it is called in shell.
– Dean Kayton
May 27 at 10:03
Does it work if you source the script? Is the bash returned by
env
the same as your shell?– Panki
May 27 at 9:56
Does it work if you source the script? Is the bash returned by
env
the same as your shell?– Panki
May 27 at 9:56
Sourcing the script works, but I need it to work when calling the script. I don't know if I follow your second question but I have included the difference of when
env
is called in script and when it is called in shell.– Dean Kayton
May 27 at 10:03
Sourcing the script works, but I need it to work when calling the script. I don't know if I follow your second question but I have included the difference of when
env
is called in script and when it is called in shell.– Dean Kayton
May 27 at 10:03
add a comment
|
1 Answer
1
active
oldest
votes
The !(...)
Korn shell extended operator is only available in bash
when you turn the extglob
option on (it is off by default).
You may have extglob
turned on in your interactive shell via ~/.bashrc
or other initialization file, but notice that those files are not sourced when running scripts, and that option is not inherited from the calling shell (unless the BASHOPTS
variable in the environment, but it would be a bad idea to have it there).
Explicitly turning it on with
shopt -s extglob
at the beginning of your script should work.
Notice that the shopt -s extglob
only has effect beginning with the next line which wasn't already parsed. This means that you cannot use shopt -s extglob
like set -f
, to only turn the extended patterns on in a subshell:
# this won't work
(
shopt -s extglob
echo !(no such file)
)
You'd have to do something like:
(
shopt -s extglob
eval 'echo !(no such file)'
)
1
@DeanKayton, the (confusingly named)shopt
command and theextglob
option are "standard" inbash
, not insh
. If you want ash
equivalent, you can always dofor f in /path/to/*.txt; do case ${f##*/} in (*example.txt) continue; esac; ...; done
– Stéphane Chazelas
May 27 at 10:16
I made the mistake of puttingshopt -s extglob
command immediately before the!(...)
Korn shell extended operator was needed. This did not work at all, the command works when it is on the first line of the script. Can you comment as to why that is the case?
– Dean Kayton
May 28 at 8:40
2
That's a bug in bash.shopt -s extglob
only has effect beginning with the next line. There's really nothing you can do about it, than putting them on separate lines.
– mosvy
May 28 at 8:52
Notice that the extglob patterns inbash
are not really like those fromksh93
; you cannot write something liketouch bar baar baaar baaaar; echo b{2,3}(a)r
to do regex-like quantifiers.
– mosvy
May 28 at 9:19
2
Yeah, you cannot turn it on in a function, because a function gets parsed as a single unit, just like the(...)
subshell from my example. (And btw, theshopt
options, unlike theset
options, cannot be made local to the function withlocal -
, anyways). Another similar quirk/bug is with thefailglob
option -- a failed glob will zap the whole line/parsing unit, not just the command it's used in, and not even aneval
will help with it ;-)(shopt -s failglob; eval 'echo hehe*'; echo DONE)
– mosvy
May 29 at 21:02
|
show 1 more 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/4.0/"u003ecc by-sa 4.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%2f521287%2ffile-globbing-pattern-example-behaves-differently-in-bash-script-than-it-d%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The !(...)
Korn shell extended operator is only available in bash
when you turn the extglob
option on (it is off by default).
You may have extglob
turned on in your interactive shell via ~/.bashrc
or other initialization file, but notice that those files are not sourced when running scripts, and that option is not inherited from the calling shell (unless the BASHOPTS
variable in the environment, but it would be a bad idea to have it there).
Explicitly turning it on with
shopt -s extglob
at the beginning of your script should work.
Notice that the shopt -s extglob
only has effect beginning with the next line which wasn't already parsed. This means that you cannot use shopt -s extglob
like set -f
, to only turn the extended patterns on in a subshell:
# this won't work
(
shopt -s extglob
echo !(no such file)
)
You'd have to do something like:
(
shopt -s extglob
eval 'echo !(no such file)'
)
1
@DeanKayton, the (confusingly named)shopt
command and theextglob
option are "standard" inbash
, not insh
. If you want ash
equivalent, you can always dofor f in /path/to/*.txt; do case ${f##*/} in (*example.txt) continue; esac; ...; done
– Stéphane Chazelas
May 27 at 10:16
I made the mistake of puttingshopt -s extglob
command immediately before the!(...)
Korn shell extended operator was needed. This did not work at all, the command works when it is on the first line of the script. Can you comment as to why that is the case?
– Dean Kayton
May 28 at 8:40
2
That's a bug in bash.shopt -s extglob
only has effect beginning with the next line. There's really nothing you can do about it, than putting them on separate lines.
– mosvy
May 28 at 8:52
Notice that the extglob patterns inbash
are not really like those fromksh93
; you cannot write something liketouch bar baar baaar baaaar; echo b{2,3}(a)r
to do regex-like quantifiers.
– mosvy
May 28 at 9:19
2
Yeah, you cannot turn it on in a function, because a function gets parsed as a single unit, just like the(...)
subshell from my example. (And btw, theshopt
options, unlike theset
options, cannot be made local to the function withlocal -
, anyways). Another similar quirk/bug is with thefailglob
option -- a failed glob will zap the whole line/parsing unit, not just the command it's used in, and not even aneval
will help with it ;-)(shopt -s failglob; eval 'echo hehe*'; echo DONE)
– mosvy
May 29 at 21:02
|
show 1 more comment
The !(...)
Korn shell extended operator is only available in bash
when you turn the extglob
option on (it is off by default).
You may have extglob
turned on in your interactive shell via ~/.bashrc
or other initialization file, but notice that those files are not sourced when running scripts, and that option is not inherited from the calling shell (unless the BASHOPTS
variable in the environment, but it would be a bad idea to have it there).
Explicitly turning it on with
shopt -s extglob
at the beginning of your script should work.
Notice that the shopt -s extglob
only has effect beginning with the next line which wasn't already parsed. This means that you cannot use shopt -s extglob
like set -f
, to only turn the extended patterns on in a subshell:
# this won't work
(
shopt -s extglob
echo !(no such file)
)
You'd have to do something like:
(
shopt -s extglob
eval 'echo !(no such file)'
)
1
@DeanKayton, the (confusingly named)shopt
command and theextglob
option are "standard" inbash
, not insh
. If you want ash
equivalent, you can always dofor f in /path/to/*.txt; do case ${f##*/} in (*example.txt) continue; esac; ...; done
– Stéphane Chazelas
May 27 at 10:16
I made the mistake of puttingshopt -s extglob
command immediately before the!(...)
Korn shell extended operator was needed. This did not work at all, the command works when it is on the first line of the script. Can you comment as to why that is the case?
– Dean Kayton
May 28 at 8:40
2
That's a bug in bash.shopt -s extglob
only has effect beginning with the next line. There's really nothing you can do about it, than putting them on separate lines.
– mosvy
May 28 at 8:52
Notice that the extglob patterns inbash
are not really like those fromksh93
; you cannot write something liketouch bar baar baaar baaaar; echo b{2,3}(a)r
to do regex-like quantifiers.
– mosvy
May 28 at 9:19
2
Yeah, you cannot turn it on in a function, because a function gets parsed as a single unit, just like the(...)
subshell from my example. (And btw, theshopt
options, unlike theset
options, cannot be made local to the function withlocal -
, anyways). Another similar quirk/bug is with thefailglob
option -- a failed glob will zap the whole line/parsing unit, not just the command it's used in, and not even aneval
will help with it ;-)(shopt -s failglob; eval 'echo hehe*'; echo DONE)
– mosvy
May 29 at 21:02
|
show 1 more comment
The !(...)
Korn shell extended operator is only available in bash
when you turn the extglob
option on (it is off by default).
You may have extglob
turned on in your interactive shell via ~/.bashrc
or other initialization file, but notice that those files are not sourced when running scripts, and that option is not inherited from the calling shell (unless the BASHOPTS
variable in the environment, but it would be a bad idea to have it there).
Explicitly turning it on with
shopt -s extglob
at the beginning of your script should work.
Notice that the shopt -s extglob
only has effect beginning with the next line which wasn't already parsed. This means that you cannot use shopt -s extglob
like set -f
, to only turn the extended patterns on in a subshell:
# this won't work
(
shopt -s extglob
echo !(no such file)
)
You'd have to do something like:
(
shopt -s extglob
eval 'echo !(no such file)'
)
The !(...)
Korn shell extended operator is only available in bash
when you turn the extglob
option on (it is off by default).
You may have extglob
turned on in your interactive shell via ~/.bashrc
or other initialization file, but notice that those files are not sourced when running scripts, and that option is not inherited from the calling shell (unless the BASHOPTS
variable in the environment, but it would be a bad idea to have it there).
Explicitly turning it on with
shopt -s extglob
at the beginning of your script should work.
Notice that the shopt -s extglob
only has effect beginning with the next line which wasn't already parsed. This means that you cannot use shopt -s extglob
like set -f
, to only turn the extended patterns on in a subshell:
# this won't work
(
shopt -s extglob
echo !(no such file)
)
You'd have to do something like:
(
shopt -s extglob
eval 'echo !(no such file)'
)
edited May 28 at 12:54
Stéphane Chazelas
336k58 gold badges656 silver badges1035 bronze badges
336k58 gold badges656 silver badges1035 bronze badges
answered May 27 at 10:02
mosvymosvy
17.6k2 gold badges24 silver badges55 bronze badges
17.6k2 gold badges24 silver badges55 bronze badges
1
@DeanKayton, the (confusingly named)shopt
command and theextglob
option are "standard" inbash
, not insh
. If you want ash
equivalent, you can always dofor f in /path/to/*.txt; do case ${f##*/} in (*example.txt) continue; esac; ...; done
– Stéphane Chazelas
May 27 at 10:16
I made the mistake of puttingshopt -s extglob
command immediately before the!(...)
Korn shell extended operator was needed. This did not work at all, the command works when it is on the first line of the script. Can you comment as to why that is the case?
– Dean Kayton
May 28 at 8:40
2
That's a bug in bash.shopt -s extglob
only has effect beginning with the next line. There's really nothing you can do about it, than putting them on separate lines.
– mosvy
May 28 at 8:52
Notice that the extglob patterns inbash
are not really like those fromksh93
; you cannot write something liketouch bar baar baaar baaaar; echo b{2,3}(a)r
to do regex-like quantifiers.
– mosvy
May 28 at 9:19
2
Yeah, you cannot turn it on in a function, because a function gets parsed as a single unit, just like the(...)
subshell from my example. (And btw, theshopt
options, unlike theset
options, cannot be made local to the function withlocal -
, anyways). Another similar quirk/bug is with thefailglob
option -- a failed glob will zap the whole line/parsing unit, not just the command it's used in, and not even aneval
will help with it ;-)(shopt -s failglob; eval 'echo hehe*'; echo DONE)
– mosvy
May 29 at 21:02
|
show 1 more comment
1
@DeanKayton, the (confusingly named)shopt
command and theextglob
option are "standard" inbash
, not insh
. If you want ash
equivalent, you can always dofor f in /path/to/*.txt; do case ${f##*/} in (*example.txt) continue; esac; ...; done
– Stéphane Chazelas
May 27 at 10:16
I made the mistake of puttingshopt -s extglob
command immediately before the!(...)
Korn shell extended operator was needed. This did not work at all, the command works when it is on the first line of the script. Can you comment as to why that is the case?
– Dean Kayton
May 28 at 8:40
2
That's a bug in bash.shopt -s extglob
only has effect beginning with the next line. There's really nothing you can do about it, than putting them on separate lines.
– mosvy
May 28 at 8:52
Notice that the extglob patterns inbash
are not really like those fromksh93
; you cannot write something liketouch bar baar baaar baaaar; echo b{2,3}(a)r
to do regex-like quantifiers.
– mosvy
May 28 at 9:19
2
Yeah, you cannot turn it on in a function, because a function gets parsed as a single unit, just like the(...)
subshell from my example. (And btw, theshopt
options, unlike theset
options, cannot be made local to the function withlocal -
, anyways). Another similar quirk/bug is with thefailglob
option -- a failed glob will zap the whole line/parsing unit, not just the command it's used in, and not even aneval
will help with it ;-)(shopt -s failglob; eval 'echo hehe*'; echo DONE)
– mosvy
May 29 at 21:02
1
1
@DeanKayton, the (confusingly named)
shopt
command and the extglob
option are "standard" in bash
, not in sh
. If you want a sh
equivalent, you can always do for f in /path/to/*.txt; do case ${f##*/} in (*example.txt) continue; esac; ...; done
– Stéphane Chazelas
May 27 at 10:16
@DeanKayton, the (confusingly named)
shopt
command and the extglob
option are "standard" in bash
, not in sh
. If you want a sh
equivalent, you can always do for f in /path/to/*.txt; do case ${f##*/} in (*example.txt) continue; esac; ...; done
– Stéphane Chazelas
May 27 at 10:16
I made the mistake of putting
shopt -s extglob
command immediately before the !(...)
Korn shell extended operator was needed. This did not work at all, the command works when it is on the first line of the script. Can you comment as to why that is the case?– Dean Kayton
May 28 at 8:40
I made the mistake of putting
shopt -s extglob
command immediately before the !(...)
Korn shell extended operator was needed. This did not work at all, the command works when it is on the first line of the script. Can you comment as to why that is the case?– Dean Kayton
May 28 at 8:40
2
2
That's a bug in bash.
shopt -s extglob
only has effect beginning with the next line. There's really nothing you can do about it, than putting them on separate lines.– mosvy
May 28 at 8:52
That's a bug in bash.
shopt -s extglob
only has effect beginning with the next line. There's really nothing you can do about it, than putting them on separate lines.– mosvy
May 28 at 8:52
Notice that the extglob patterns in
bash
are not really like those from ksh93
; you cannot write something like touch bar baar baaar baaaar; echo b{2,3}(a)r
to do regex-like quantifiers.– mosvy
May 28 at 9:19
Notice that the extglob patterns in
bash
are not really like those from ksh93
; you cannot write something like touch bar baar baaar baaaar; echo b{2,3}(a)r
to do regex-like quantifiers.– mosvy
May 28 at 9:19
2
2
Yeah, you cannot turn it on in a function, because a function gets parsed as a single unit, just like the
(...)
subshell from my example. (And btw, the shopt
options, unlike the set
options, cannot be made local to the function with local -
, anyways). Another similar quirk/bug is with the failglob
option -- a failed glob will zap the whole line/parsing unit, not just the command it's used in, and not even an eval
will help with it ;-) (shopt -s failglob; eval 'echo hehe*'; echo DONE)
– mosvy
May 29 at 21:02
Yeah, you cannot turn it on in a function, because a function gets parsed as a single unit, just like the
(...)
subshell from my example. (And btw, the shopt
options, unlike the set
options, cannot be made local to the function with local -
, anyways). Another similar quirk/bug is with the failglob
option -- a failed glob will zap the whole line/parsing unit, not just the command it's used in, and not even an eval
will help with it ;-) (shopt -s failglob; eval 'echo hehe*'; echo DONE)
– mosvy
May 29 at 21:02
|
show 1 more 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%2f521287%2ffile-globbing-pattern-example-behaves-differently-in-bash-script-than-it-d%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
Does it work if you source the script? Is the bash returned by
env
the same as your shell?– Panki
May 27 at 9:56
Sourcing the script works, but I need it to work when calling the script. I don't know if I follow your second question but I have included the difference of when
env
is called in script and when it is called in shell.– Dean Kayton
May 27 at 10:03