How to use Bash for sh in Ubuntu
Clash Royale CLAN TAG#URR8PPP
up vote
9
down vote
favorite
I am installing a huge program, which has its resources as an rpm
file. It stuck at the line of
#!/bin/sh
SCITEGICPERLBIN=`dirname $0`
SCITEGICPERLHOME=`dirname $SCITEGICPERLBIN`
if [ $SCITEGICPERLHOME == "." ]
Apparently, sh
work for bash
in Red Hat Linux with this syntax, but it gives the error of unexpected operator
in Ubuntu.
I cannot change the script to bash
as the script comes from the rpm
package. I can extract and repack the rpm
package, but there might be many of such scripts.
Is there a way to change the shell default to treat #!/bin/sh
as bash
or anything else, which can handle the [
operator?
bash shell-script shell ubuntu rpm
add a comment |Â
up vote
9
down vote
favorite
I am installing a huge program, which has its resources as an rpm
file. It stuck at the line of
#!/bin/sh
SCITEGICPERLBIN=`dirname $0`
SCITEGICPERLHOME=`dirname $SCITEGICPERLBIN`
if [ $SCITEGICPERLHOME == "." ]
Apparently, sh
work for bash
in Red Hat Linux with this syntax, but it gives the error of unexpected operator
in Ubuntu.
I cannot change the script to bash
as the script comes from the rpm
package. I can extract and repack the rpm
package, but there might be many of such scripts.
Is there a way to change the shell default to treat #!/bin/sh
as bash
or anything else, which can handle the [
operator?
bash shell-script shell ubuntu rpm
5
The only thing wrong is the==
that should be=
. That, and that the variable expansions should be double quoted.
â Kusalananda
May 8 at 11:29
4
[
is not an operator, but a builtin command that is calledtest
. The unexpected operator is==
and this should be replaced by=
because it is not POSIX compliant.
â schily
May 8 at 11:34
The second only thing that is wrong is that$SCITEGICPERLHOME
should be quoted.
â l0b0
May 8 at 19:35
11
You should complain to the author of the program. If they use#!/bin/sh
, they should make sure they only use POSIX shell features, notbash
extensions. This programmer is very sloppy. He should either fix his code or use#!/bin/bash
.
â Barmar
May 8 at 19:44
For people wondering about other similar issues here is a list of "Bashisms". Also see this question.
â Captain Man
May 8 at 23:00
add a comment |Â
up vote
9
down vote
favorite
up vote
9
down vote
favorite
I am installing a huge program, which has its resources as an rpm
file. It stuck at the line of
#!/bin/sh
SCITEGICPERLBIN=`dirname $0`
SCITEGICPERLHOME=`dirname $SCITEGICPERLBIN`
if [ $SCITEGICPERLHOME == "." ]
Apparently, sh
work for bash
in Red Hat Linux with this syntax, but it gives the error of unexpected operator
in Ubuntu.
I cannot change the script to bash
as the script comes from the rpm
package. I can extract and repack the rpm
package, but there might be many of such scripts.
Is there a way to change the shell default to treat #!/bin/sh
as bash
or anything else, which can handle the [
operator?
bash shell-script shell ubuntu rpm
I am installing a huge program, which has its resources as an rpm
file. It stuck at the line of
#!/bin/sh
SCITEGICPERLBIN=`dirname $0`
SCITEGICPERLHOME=`dirname $SCITEGICPERLBIN`
if [ $SCITEGICPERLHOME == "." ]
Apparently, sh
work for bash
in Red Hat Linux with this syntax, but it gives the error of unexpected operator
in Ubuntu.
I cannot change the script to bash
as the script comes from the rpm
package. I can extract and repack the rpm
package, but there might be many of such scripts.
Is there a way to change the shell default to treat #!/bin/sh
as bash
or anything else, which can handle the [
operator?
bash shell-script shell ubuntu rpm
edited May 8 at 14:01
Peter Mortensen
77548
77548
asked May 8 at 11:08
Googlebot
473420
473420
5
The only thing wrong is the==
that should be=
. That, and that the variable expansions should be double quoted.
â Kusalananda
May 8 at 11:29
4
[
is not an operator, but a builtin command that is calledtest
. The unexpected operator is==
and this should be replaced by=
because it is not POSIX compliant.
â schily
May 8 at 11:34
The second only thing that is wrong is that$SCITEGICPERLHOME
should be quoted.
â l0b0
May 8 at 19:35
11
You should complain to the author of the program. If they use#!/bin/sh
, they should make sure they only use POSIX shell features, notbash
extensions. This programmer is very sloppy. He should either fix his code or use#!/bin/bash
.
â Barmar
May 8 at 19:44
For people wondering about other similar issues here is a list of "Bashisms". Also see this question.
â Captain Man
May 8 at 23:00
add a comment |Â
5
The only thing wrong is the==
that should be=
. That, and that the variable expansions should be double quoted.
â Kusalananda
May 8 at 11:29
4
[
is not an operator, but a builtin command that is calledtest
. The unexpected operator is==
and this should be replaced by=
because it is not POSIX compliant.
â schily
May 8 at 11:34
The second only thing that is wrong is that$SCITEGICPERLHOME
should be quoted.
â l0b0
May 8 at 19:35
11
You should complain to the author of the program. If they use#!/bin/sh
, they should make sure they only use POSIX shell features, notbash
extensions. This programmer is very sloppy. He should either fix his code or use#!/bin/bash
.
â Barmar
May 8 at 19:44
For people wondering about other similar issues here is a list of "Bashisms". Also see this question.
â Captain Man
May 8 at 23:00
5
5
The only thing wrong is the
==
that should be =
. That, and that the variable expansions should be double quoted.â Kusalananda
May 8 at 11:29
The only thing wrong is the
==
that should be =
. That, and that the variable expansions should be double quoted.â Kusalananda
May 8 at 11:29
4
4
[
is not an operator, but a builtin command that is called test
. The unexpected operator is ==
and this should be replaced by =
because it is not POSIX compliant.â schily
May 8 at 11:34
[
is not an operator, but a builtin command that is called test
. The unexpected operator is ==
and this should be replaced by =
because it is not POSIX compliant.â schily
May 8 at 11:34
The second only thing that is wrong is that
$SCITEGICPERLHOME
should be quoted.â l0b0
May 8 at 19:35
The second only thing that is wrong is that
$SCITEGICPERLHOME
should be quoted.â l0b0
May 8 at 19:35
11
11
You should complain to the author of the program. If they use
#!/bin/sh
, they should make sure they only use POSIX shell features, not bash
extensions. This programmer is very sloppy. He should either fix his code or use #!/bin/bash
.â Barmar
May 8 at 19:44
You should complain to the author of the program. If they use
#!/bin/sh
, they should make sure they only use POSIX shell features, not bash
extensions. This programmer is very sloppy. He should either fix his code or use #!/bin/bash
.â Barmar
May 8 at 19:44
For people wondering about other similar issues here is a list of "Bashisms". Also see this question.
â Captain Man
May 8 at 23:00
For people wondering about other similar issues here is a list of "Bashisms". Also see this question.
â Captain Man
May 8 at 23:00
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
16
down vote
accepted
There are multiple programs that implement the language of /bin/sh
. On Ubuntu, /bin/sh
is dash, which is designed to be fast, to use a small amount of memory, and doesn't support much more than the minimum expected from /bin/sh
. On RHEL, /bin/sh
is bash, which is slower and uses more memory but has more features. One of these features is the ==
operator for the [
conditional syntax. Dash supports [
, which is a basic sh feature, but it doesn't have the ==
operator which is a bash (and ksh and zsh) extension.
You can switch your system to using bash. On Ubuntu, /bin/sh
is a symbolic link to dash
. You can make it a symbolic link to bash
instead:
sudo ln -s bash /bin/sh.bash
sudo mv /bin/sh.bash /bin/sh
Keep a terminal open and check that you can still run some sh
scripts after that. If you mess up this command, it'll make your system unusable. (By the way, the reason I used the multiple commands above rather than the straightforward-looking sudo ln -sf bash /bin/sh
is that ln -sf
is not atomic. In the admittedly unlikely case your computer crashed during this operation, you'd need to boot from rescue media to restore it. In contrast, mv
is atomic.)
You can keep bash as /bin/sh
, but it'll make your system a bit slower. It's even conceivable that some system script is incompatible with bash, although that's unlikely since bash is mostly a superset of dash. So I recommend restoring dash as /bin/sh
:
sudo ln -s dash /bin/sh.dash
sudo mv /bin/sh.dash /bin/sh
In my not so humble opinion, if some script fails when/bin/sh
is Bash, it's a bug either in the system (the package with the script), or in Bash'ssh
-mode. Like Stephen says, the system explicitly allows for setting/bin/sh
back to Bash, viadpkg-reconfigure
. It's also mentioned as a possibility in the Ubuntu wiki on this matter: wiki.ubuntu.com/DashAsBinSh
â ilkkachu
May 8 at 11:50
5
@ilkkachu Yes, if a script fails if/bin/sh
is bash, it's a bug. However, bugs happen. I recommend sticking to the default if you're not capable and willing to diagnose such bugs because other people have tested it for you. I used dash as/bin/sh
before it was officially supported on Debian, but this was a risk I took, knowing that I'd be able to cope if something happened.
â Gilles
May 8 at 11:55
add a comment |Â
up vote
34
down vote
To switch sh
to bash
(instead of dash
, the default), reconfigure dash
(yes, itâÂÂs somewhat counter-intuitive):
sudo dpkg-reconfigure dash
This will ask whether you want dash
to be the default system shell; answer âÂÂNoâ (Tab then Enter) and bash
will become the default instead (i.e. /bin/sh
will point to /bin/bash
).
1
Your solution is indeed the most reasonable one, but I accepted another answer because of detailed descriptions clarifying the issue. Sorry for any inconvenience.
â Googlebot
May 8 at 11:52
@Googlebot no need to apologise, choosing the accepted answer is the askerâÂÂs privilege. And I got a gold badge out of it ;-).
â Stephen Kitt
May 9 at 14:34
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
16
down vote
accepted
There are multiple programs that implement the language of /bin/sh
. On Ubuntu, /bin/sh
is dash, which is designed to be fast, to use a small amount of memory, and doesn't support much more than the minimum expected from /bin/sh
. On RHEL, /bin/sh
is bash, which is slower and uses more memory but has more features. One of these features is the ==
operator for the [
conditional syntax. Dash supports [
, which is a basic sh feature, but it doesn't have the ==
operator which is a bash (and ksh and zsh) extension.
You can switch your system to using bash. On Ubuntu, /bin/sh
is a symbolic link to dash
. You can make it a symbolic link to bash
instead:
sudo ln -s bash /bin/sh.bash
sudo mv /bin/sh.bash /bin/sh
Keep a terminal open and check that you can still run some sh
scripts after that. If you mess up this command, it'll make your system unusable. (By the way, the reason I used the multiple commands above rather than the straightforward-looking sudo ln -sf bash /bin/sh
is that ln -sf
is not atomic. In the admittedly unlikely case your computer crashed during this operation, you'd need to boot from rescue media to restore it. In contrast, mv
is atomic.)
You can keep bash as /bin/sh
, but it'll make your system a bit slower. It's even conceivable that some system script is incompatible with bash, although that's unlikely since bash is mostly a superset of dash. So I recommend restoring dash as /bin/sh
:
sudo ln -s dash /bin/sh.dash
sudo mv /bin/sh.dash /bin/sh
In my not so humble opinion, if some script fails when/bin/sh
is Bash, it's a bug either in the system (the package with the script), or in Bash'ssh
-mode. Like Stephen says, the system explicitly allows for setting/bin/sh
back to Bash, viadpkg-reconfigure
. It's also mentioned as a possibility in the Ubuntu wiki on this matter: wiki.ubuntu.com/DashAsBinSh
â ilkkachu
May 8 at 11:50
5
@ilkkachu Yes, if a script fails if/bin/sh
is bash, it's a bug. However, bugs happen. I recommend sticking to the default if you're not capable and willing to diagnose such bugs because other people have tested it for you. I used dash as/bin/sh
before it was officially supported on Debian, but this was a risk I took, knowing that I'd be able to cope if something happened.
â Gilles
May 8 at 11:55
add a comment |Â
up vote
16
down vote
accepted
There are multiple programs that implement the language of /bin/sh
. On Ubuntu, /bin/sh
is dash, which is designed to be fast, to use a small amount of memory, and doesn't support much more than the minimum expected from /bin/sh
. On RHEL, /bin/sh
is bash, which is slower and uses more memory but has more features. One of these features is the ==
operator for the [
conditional syntax. Dash supports [
, which is a basic sh feature, but it doesn't have the ==
operator which is a bash (and ksh and zsh) extension.
You can switch your system to using bash. On Ubuntu, /bin/sh
is a symbolic link to dash
. You can make it a symbolic link to bash
instead:
sudo ln -s bash /bin/sh.bash
sudo mv /bin/sh.bash /bin/sh
Keep a terminal open and check that you can still run some sh
scripts after that. If you mess up this command, it'll make your system unusable. (By the way, the reason I used the multiple commands above rather than the straightforward-looking sudo ln -sf bash /bin/sh
is that ln -sf
is not atomic. In the admittedly unlikely case your computer crashed during this operation, you'd need to boot from rescue media to restore it. In contrast, mv
is atomic.)
You can keep bash as /bin/sh
, but it'll make your system a bit slower. It's even conceivable that some system script is incompatible with bash, although that's unlikely since bash is mostly a superset of dash. So I recommend restoring dash as /bin/sh
:
sudo ln -s dash /bin/sh.dash
sudo mv /bin/sh.dash /bin/sh
In my not so humble opinion, if some script fails when/bin/sh
is Bash, it's a bug either in the system (the package with the script), or in Bash'ssh
-mode. Like Stephen says, the system explicitly allows for setting/bin/sh
back to Bash, viadpkg-reconfigure
. It's also mentioned as a possibility in the Ubuntu wiki on this matter: wiki.ubuntu.com/DashAsBinSh
â ilkkachu
May 8 at 11:50
5
@ilkkachu Yes, if a script fails if/bin/sh
is bash, it's a bug. However, bugs happen. I recommend sticking to the default if you're not capable and willing to diagnose such bugs because other people have tested it for you. I used dash as/bin/sh
before it was officially supported on Debian, but this was a risk I took, knowing that I'd be able to cope if something happened.
â Gilles
May 8 at 11:55
add a comment |Â
up vote
16
down vote
accepted
up vote
16
down vote
accepted
There are multiple programs that implement the language of /bin/sh
. On Ubuntu, /bin/sh
is dash, which is designed to be fast, to use a small amount of memory, and doesn't support much more than the minimum expected from /bin/sh
. On RHEL, /bin/sh
is bash, which is slower and uses more memory but has more features. One of these features is the ==
operator for the [
conditional syntax. Dash supports [
, which is a basic sh feature, but it doesn't have the ==
operator which is a bash (and ksh and zsh) extension.
You can switch your system to using bash. On Ubuntu, /bin/sh
is a symbolic link to dash
. You can make it a symbolic link to bash
instead:
sudo ln -s bash /bin/sh.bash
sudo mv /bin/sh.bash /bin/sh
Keep a terminal open and check that you can still run some sh
scripts after that. If you mess up this command, it'll make your system unusable. (By the way, the reason I used the multiple commands above rather than the straightforward-looking sudo ln -sf bash /bin/sh
is that ln -sf
is not atomic. In the admittedly unlikely case your computer crashed during this operation, you'd need to boot from rescue media to restore it. In contrast, mv
is atomic.)
You can keep bash as /bin/sh
, but it'll make your system a bit slower. It's even conceivable that some system script is incompatible with bash, although that's unlikely since bash is mostly a superset of dash. So I recommend restoring dash as /bin/sh
:
sudo ln -s dash /bin/sh.dash
sudo mv /bin/sh.dash /bin/sh
There are multiple programs that implement the language of /bin/sh
. On Ubuntu, /bin/sh
is dash, which is designed to be fast, to use a small amount of memory, and doesn't support much more than the minimum expected from /bin/sh
. On RHEL, /bin/sh
is bash, which is slower and uses more memory but has more features. One of these features is the ==
operator for the [
conditional syntax. Dash supports [
, which is a basic sh feature, but it doesn't have the ==
operator which is a bash (and ksh and zsh) extension.
You can switch your system to using bash. On Ubuntu, /bin/sh
is a symbolic link to dash
. You can make it a symbolic link to bash
instead:
sudo ln -s bash /bin/sh.bash
sudo mv /bin/sh.bash /bin/sh
Keep a terminal open and check that you can still run some sh
scripts after that. If you mess up this command, it'll make your system unusable. (By the way, the reason I used the multiple commands above rather than the straightforward-looking sudo ln -sf bash /bin/sh
is that ln -sf
is not atomic. In the admittedly unlikely case your computer crashed during this operation, you'd need to boot from rescue media to restore it. In contrast, mv
is atomic.)
You can keep bash as /bin/sh
, but it'll make your system a bit slower. It's even conceivable that some system script is incompatible with bash, although that's unlikely since bash is mostly a superset of dash. So I recommend restoring dash as /bin/sh
:
sudo ln -s dash /bin/sh.dash
sudo mv /bin/sh.dash /bin/sh
answered May 8 at 11:33
Gilles
503k1189951522
503k1189951522
In my not so humble opinion, if some script fails when/bin/sh
is Bash, it's a bug either in the system (the package with the script), or in Bash'ssh
-mode. Like Stephen says, the system explicitly allows for setting/bin/sh
back to Bash, viadpkg-reconfigure
. It's also mentioned as a possibility in the Ubuntu wiki on this matter: wiki.ubuntu.com/DashAsBinSh
â ilkkachu
May 8 at 11:50
5
@ilkkachu Yes, if a script fails if/bin/sh
is bash, it's a bug. However, bugs happen. I recommend sticking to the default if you're not capable and willing to diagnose such bugs because other people have tested it for you. I used dash as/bin/sh
before it was officially supported on Debian, but this was a risk I took, knowing that I'd be able to cope if something happened.
â Gilles
May 8 at 11:55
add a comment |Â
In my not so humble opinion, if some script fails when/bin/sh
is Bash, it's a bug either in the system (the package with the script), or in Bash'ssh
-mode. Like Stephen says, the system explicitly allows for setting/bin/sh
back to Bash, viadpkg-reconfigure
. It's also mentioned as a possibility in the Ubuntu wiki on this matter: wiki.ubuntu.com/DashAsBinSh
â ilkkachu
May 8 at 11:50
5
@ilkkachu Yes, if a script fails if/bin/sh
is bash, it's a bug. However, bugs happen. I recommend sticking to the default if you're not capable and willing to diagnose such bugs because other people have tested it for you. I used dash as/bin/sh
before it was officially supported on Debian, but this was a risk I took, knowing that I'd be able to cope if something happened.
â Gilles
May 8 at 11:55
In my not so humble opinion, if some script fails when
/bin/sh
is Bash, it's a bug either in the system (the package with the script), or in Bash's sh
-mode. Like Stephen says, the system explicitly allows for setting /bin/sh
back to Bash, via dpkg-reconfigure
. It's also mentioned as a possibility in the Ubuntu wiki on this matter: wiki.ubuntu.com/DashAsBinShâ ilkkachu
May 8 at 11:50
In my not so humble opinion, if some script fails when
/bin/sh
is Bash, it's a bug either in the system (the package with the script), or in Bash's sh
-mode. Like Stephen says, the system explicitly allows for setting /bin/sh
back to Bash, via dpkg-reconfigure
. It's also mentioned as a possibility in the Ubuntu wiki on this matter: wiki.ubuntu.com/DashAsBinShâ ilkkachu
May 8 at 11:50
5
5
@ilkkachu Yes, if a script fails if
/bin/sh
is bash, it's a bug. However, bugs happen. I recommend sticking to the default if you're not capable and willing to diagnose such bugs because other people have tested it for you. I used dash as /bin/sh
before it was officially supported on Debian, but this was a risk I took, knowing that I'd be able to cope if something happened.â Gilles
May 8 at 11:55
@ilkkachu Yes, if a script fails if
/bin/sh
is bash, it's a bug. However, bugs happen. I recommend sticking to the default if you're not capable and willing to diagnose such bugs because other people have tested it for you. I used dash as /bin/sh
before it was officially supported on Debian, but this was a risk I took, knowing that I'd be able to cope if something happened.â Gilles
May 8 at 11:55
add a comment |Â
up vote
34
down vote
To switch sh
to bash
(instead of dash
, the default), reconfigure dash
(yes, itâÂÂs somewhat counter-intuitive):
sudo dpkg-reconfigure dash
This will ask whether you want dash
to be the default system shell; answer âÂÂNoâ (Tab then Enter) and bash
will become the default instead (i.e. /bin/sh
will point to /bin/bash
).
1
Your solution is indeed the most reasonable one, but I accepted another answer because of detailed descriptions clarifying the issue. Sorry for any inconvenience.
â Googlebot
May 8 at 11:52
@Googlebot no need to apologise, choosing the accepted answer is the askerâÂÂs privilege. And I got a gold badge out of it ;-).
â Stephen Kitt
May 9 at 14:34
add a comment |Â
up vote
34
down vote
To switch sh
to bash
(instead of dash
, the default), reconfigure dash
(yes, itâÂÂs somewhat counter-intuitive):
sudo dpkg-reconfigure dash
This will ask whether you want dash
to be the default system shell; answer âÂÂNoâ (Tab then Enter) and bash
will become the default instead (i.e. /bin/sh
will point to /bin/bash
).
1
Your solution is indeed the most reasonable one, but I accepted another answer because of detailed descriptions clarifying the issue. Sorry for any inconvenience.
â Googlebot
May 8 at 11:52
@Googlebot no need to apologise, choosing the accepted answer is the askerâÂÂs privilege. And I got a gold badge out of it ;-).
â Stephen Kitt
May 9 at 14:34
add a comment |Â
up vote
34
down vote
up vote
34
down vote
To switch sh
to bash
(instead of dash
, the default), reconfigure dash
(yes, itâÂÂs somewhat counter-intuitive):
sudo dpkg-reconfigure dash
This will ask whether you want dash
to be the default system shell; answer âÂÂNoâ (Tab then Enter) and bash
will become the default instead (i.e. /bin/sh
will point to /bin/bash
).
To switch sh
to bash
(instead of dash
, the default), reconfigure dash
(yes, itâÂÂs somewhat counter-intuitive):
sudo dpkg-reconfigure dash
This will ask whether you want dash
to be the default system shell; answer âÂÂNoâ (Tab then Enter) and bash
will become the default instead (i.e. /bin/sh
will point to /bin/bash
).
answered May 8 at 11:26
Stephen Kitt
140k22302363
140k22302363
1
Your solution is indeed the most reasonable one, but I accepted another answer because of detailed descriptions clarifying the issue. Sorry for any inconvenience.
â Googlebot
May 8 at 11:52
@Googlebot no need to apologise, choosing the accepted answer is the askerâÂÂs privilege. And I got a gold badge out of it ;-).
â Stephen Kitt
May 9 at 14:34
add a comment |Â
1
Your solution is indeed the most reasonable one, but I accepted another answer because of detailed descriptions clarifying the issue. Sorry for any inconvenience.
â Googlebot
May 8 at 11:52
@Googlebot no need to apologise, choosing the accepted answer is the askerâÂÂs privilege. And I got a gold badge out of it ;-).
â Stephen Kitt
May 9 at 14:34
1
1
Your solution is indeed the most reasonable one, but I accepted another answer because of detailed descriptions clarifying the issue. Sorry for any inconvenience.
â Googlebot
May 8 at 11:52
Your solution is indeed the most reasonable one, but I accepted another answer because of detailed descriptions clarifying the issue. Sorry for any inconvenience.
â Googlebot
May 8 at 11:52
@Googlebot no need to apologise, choosing the accepted answer is the askerâÂÂs privilege. And I got a gold badge out of it ;-).
â Stephen Kitt
May 9 at 14:34
@Googlebot no need to apologise, choosing the accepted answer is the askerâÂÂs privilege. And I got a gold badge out of it ;-).
â Stephen Kitt
May 9 at 14:34
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442510%2fhow-to-use-bash-for-sh-in-ubuntu%23new-answer', 'question_page');
);
Post as a guest
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
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
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
5
The only thing wrong is the
==
that should be=
. That, and that the variable expansions should be double quoted.â Kusalananda
May 8 at 11:29
4
[
is not an operator, but a builtin command that is calledtest
. The unexpected operator is==
and this should be replaced by=
because it is not POSIX compliant.â schily
May 8 at 11:34
The second only thing that is wrong is that
$SCITEGICPERLHOME
should be quoted.â l0b0
May 8 at 19:35
11
You should complain to the author of the program. If they use
#!/bin/sh
, they should make sure they only use POSIX shell features, notbash
extensions. This programmer is very sloppy. He should either fix his code or use#!/bin/bash
.â Barmar
May 8 at 19:44
For people wondering about other similar issues here is a list of "Bashisms". Also see this question.
â Captain Man
May 8 at 23:00