Does “sh†have to be in the “/bin†directory?
Clash Royale CLAN TAG#URR8PPP
up vote
15
down vote
favorite
I have read that POSIX compliant operating systems (for example: Linux) must have the sh shell.
But is it required for sh to be in the /bin directory, or can it be in any directory?
linux shell posix
asked Jan 13 at 2:09
user270294
793
add a comment |Â
up vote
15
down vote
favorite
I have read that POSIX compliant operating systems (for example: Linux) must have the sh shell.
But is it required for sh to be in the /bin directory, or can it be in any directory?
linux shell posix
asked Jan 13 at 2:09
user270294
793
You can always use a symlink as/bin/sh, in most cases on linux, it's already a symlink tobash. It's just that lots of scripts use hardcoded/bin/sh
– cylgalad
Jan 13 at 9:11
5
Now that you have the answer that it can live anywhere it wants, you may ask yourself: how can you then portably write a shebang line forsh? And the answer is: shebang isn't part of POSIX either, so the problem doesn't even present itself.
– Jörg W Mittag
Jan 13 at 9:30
1
@JörgWMittag Yes, it's sometimes surprising how many of the things we think of as "standard" Unix features are not actually required by POSIX.
– Barmar
Jan 13 at 17:54
1
Whether or not you use a shebang is independent of whether the path/bin/shmust exist on a POSIX system.
– chepner
Jan 13 at 19:13
At least on Ubuntu-derived systems,/bin/shis a link todash. On the BSDs,/bin/shis its not a link but a separate executable, and certainly notbash.
– Rhialto
Jan 13 at 20:11
add a comment |Â
up vote
15
down vote
favorite
up vote
15
down vote
favorite
I have read that POSIX compliant operating systems (for example: Linux) must have the sh shell.
But is it required for sh to be in the /bin directory, or can it be in any directory?
linux shell posix
asked Jan 13 at 2:09
user270294
793
I have read that POSIX compliant operating systems (for example: Linux) must have the sh shell.
But is it required for sh to be in the /bin directory, or can it be in any directory?
linux shell posix
asked Jan 13 at 2:09
user270294
793
asked Jan 13 at 2:09
user270294
793
asked Jan 13 at 2:09
user270294
793
asked Jan 13 at 2:09
user270294
793
793
You can always use a symlink as/bin/sh, in most cases on linux, it's already a symlink tobash. It's just that lots of scripts use hardcoded/bin/sh
– cylgalad
Jan 13 at 9:11
5
Now that you have the answer that it can live anywhere it wants, you may ask yourself: how can you then portably write a shebang line forsh? And the answer is: shebang isn't part of POSIX either, so the problem doesn't even present itself.
– Jörg W Mittag
Jan 13 at 9:30
1
@JörgWMittag Yes, it's sometimes surprising how many of the things we think of as "standard" Unix features are not actually required by POSIX.
– Barmar
Jan 13 at 17:54
1
Whether or not you use a shebang is independent of whether the path/bin/shmust exist on a POSIX system.
– chepner
Jan 13 at 19:13
At least on Ubuntu-derived systems,/bin/shis a link todash. On the BSDs,/bin/shis its not a link but a separate executable, and certainly notbash.
– Rhialto
Jan 13 at 20:11
add a comment |Â
You can always use a symlink as/bin/sh, in most cases on linux, it's already a symlink tobash. It's just that lots of scripts use hardcoded/bin/sh
– cylgalad
Jan 13 at 9:11
5
Now that you have the answer that it can live anywhere it wants, you may ask yourself: how can you then portably write a shebang line forsh? And the answer is: shebang isn't part of POSIX either, so the problem doesn't even present itself.
– Jörg W Mittag
Jan 13 at 9:30
1
@JörgWMittag Yes, it's sometimes surprising how many of the things we think of as "standard" Unix features are not actually required by POSIX.
– Barmar
Jan 13 at 17:54
1
Whether or not you use a shebang is independent of whether the path/bin/shmust exist on a POSIX system.
– chepner
Jan 13 at 19:13
At least on Ubuntu-derived systems,/bin/shis a link todash. On the BSDs,/bin/shis its not a link but a separate executable, and certainly notbash.
– Rhialto
Jan 13 at 20:11
You can always use a symlink as
/bin/sh, in most cases on linux, it's already a symlink to bash. It's just that lots of scripts use hardcoded /bin/sh– cylgalad
Jan 13 at 9:11
You can always use a symlink as
/bin/sh, in most cases on linux, it's already a symlink to bash. It's just that lots of scripts use hardcoded /bin/sh– cylgalad
Jan 13 at 9:11
5
5
Now that you have the answer that it can live anywhere it wants, you may ask yourself: how can you then portably write a shebang line for
sh? And the answer is: shebang isn't part of POSIX either, so the problem doesn't even present itself.– Jörg W Mittag
Jan 13 at 9:30
Now that you have the answer that it can live anywhere it wants, you may ask yourself: how can you then portably write a shebang line for
sh? And the answer is: shebang isn't part of POSIX either, so the problem doesn't even present itself.– Jörg W Mittag
Jan 13 at 9:30
1
1
@JörgWMittag Yes, it's sometimes surprising how many of the things we think of as "standard" Unix features are not actually required by POSIX.
– Barmar
Jan 13 at 17:54
@JörgWMittag Yes, it's sometimes surprising how many of the things we think of as "standard" Unix features are not actually required by POSIX.
– Barmar
Jan 13 at 17:54
1
1
Whether or not you use a shebang is independent of whether the path
/bin/sh must exist on a POSIX system.– chepner
Jan 13 at 19:13
Whether or not you use a shebang is independent of whether the path
/bin/sh must exist on a POSIX system.– chepner
Jan 13 at 19:13
At least on Ubuntu-derived systems,
/bin/sh is a link to dash. On the BSDs, /bin/sh is its not a link but a separate executable, and certainly not bash.– Rhialto
Jan 13 at 20:11
At least on Ubuntu-derived systems,
/bin/sh is a link to dash. On the BSDs, /bin/sh is its not a link but a separate executable, and certainly not bash.– Rhialto
Jan 13 at 20:11
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
21
down vote
POSIX only mandates the /dev and /tmp directories to exist, and the /dev/null, /dev/tty, and /dev/console files. The standard utilities must exist, but there is no particular location specified. There may not be a /bin at all, and if there is it may not contain a sh, and if it does that may not be a POSIX sh.
You can get a valid PATH variable that includes the POSIX tools, including sh, with the getconf command:
$ PATH=$(getconf PATH)
$ sh
This can be useful on, for example, Solaris, where the default sh is not POSIX-compatible, but a compliant sh is provided and accessible in that way (because Solaris is a certified Unix). getconf PATH will include /usr/xpg4/bin at the front, which contains POSIX sh and a number of other required tools (including useless ones like cd).
answered Jan 13 at 2:25
Michael Homer
42.5k6108148
Re Solaris: ...unless you're running a Solaris "small server" installation, which omits many of the POSIX tools. See unix.stackexchange.com/q/360359/135943
– Wildcard
Jan 13 at 3:11
"Useless" ones? I'd rather call them redundant.
– Mukesh Sai Kumar
Jan 13 at 8:37
2
so how is getconf found?
– Joshua
Jan 13 at 15:03
@MukeshSaiKumar a stand-alone ‘cd’ command cannot ever work
– OrangeDog
Jan 13 at 17:03
Well, it'll "work" only for a value of working that, say, tests whether you can change to a directory, but doesn't actually leave the process that called it there. That's more functionality than none at all, though.
– Charles Duffy
Jan 13 at 17:05
 |Â
show 1 more comment
up vote
11
down vote
No, it is not required for sh to be in /bin. It explicitly cites /bin, /usr/bin, and /usr/xpg4/bin as possible locations. The POSIX spec only requires that sh be in the PATH.
The POSIX spec states:
Applications should note that the standard PATH to the shell cannot be
assumed to be either/bin/shor/usr/bin/sh, and should be determined
by interrogation of the PATH returned by getconf PATH, ensuring that
the returned pathname is an absolute pathname and not a shell
built-in.
For example, to determine the location of the standard sh utility:
command -v sh
On some implementations this might return:
/usr/xpg4/bin/sh
answered Jan 13 at 2:24
John1024
44.2k4100116
add a comment |Â
up vote
2
down vote
As others here have said, this is not strictly required for POSIX compliance.
But arguably compatibility with existing software is far more important (after all, the purpose of POSIX is to have certain things work on all conforming operating systems) and if an OS does not provide sh at /bin/sh, that will break some things.
Most obviously, scripts with #!/bin/sh rely on this path being standardized. This is not required to work; POSIX doesn't even require that #! lines are supported, although it mentions that such functionality is common:
Another way that some historical implementations handle shell scripts is by recognizing the first two bytes of the file as the character string "#!" and using the remainder of the first line of the file as the name of the command interpreter to execute.
But if that isn't supported, a lot of existing software will break or require additional work to port.
answered Jan 13 at 22:33
Ian D. Scott
1616
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
21
down vote
POSIX only mandates the /dev and /tmp directories to exist, and the /dev/null, /dev/tty, and /dev/console files. The standard utilities must exist, but there is no particular location specified. There may not be a /bin at all, and if there is it may not contain a sh, and if it does that may not be a POSIX sh.
You can get a valid PATH variable that includes the POSIX tools, including sh, with the getconf command:
$ PATH=$(getconf PATH)
$ sh
This can be useful on, for example, Solaris, where the default sh is not POSIX-compatible, but a compliant sh is provided and accessible in that way (because Solaris is a certified Unix). getconf PATH will include /usr/xpg4/bin at the front, which contains POSIX sh and a number of other required tools (including useless ones like cd).
answered Jan 13 at 2:25
Michael Homer
42.5k6108148
Re Solaris: ...unless you're running a Solaris "small server" installation, which omits many of the POSIX tools. See unix.stackexchange.com/q/360359/135943
– Wildcard
Jan 13 at 3:11
"Useless" ones? I'd rather call them redundant.
– Mukesh Sai Kumar
Jan 13 at 8:37
2
so how is getconf found?
– Joshua
Jan 13 at 15:03
@MukeshSaiKumar a stand-alone ‘cd’ command cannot ever work
– OrangeDog
Jan 13 at 17:03
Well, it'll "work" only for a value of working that, say, tests whether you can change to a directory, but doesn't actually leave the process that called it there. That's more functionality than none at all, though.
– Charles Duffy
Jan 13 at 17:05
 |Â
show 1 more comment
up vote
21
down vote
POSIX only mandates the /dev and /tmp directories to exist, and the /dev/null, /dev/tty, and /dev/console files. The standard utilities must exist, but there is no particular location specified. There may not be a /bin at all, and if there is it may not contain a sh, and if it does that may not be a POSIX sh.
You can get a valid PATH variable that includes the POSIX tools, including sh, with the getconf command:
$ PATH=$(getconf PATH)
$ sh
This can be useful on, for example, Solaris, where the default sh is not POSIX-compatible, but a compliant sh is provided and accessible in that way (because Solaris is a certified Unix). getconf PATH will include /usr/xpg4/bin at the front, which contains POSIX sh and a number of other required tools (including useless ones like cd).
answered Jan 13 at 2:25
Michael Homer
42.5k6108148
Re Solaris: ...unless you're running a Solaris "small server" installation, which omits many of the POSIX tools. See unix.stackexchange.com/q/360359/135943
– Wildcard
Jan 13 at 3:11
"Useless" ones? I'd rather call them redundant.
– Mukesh Sai Kumar
Jan 13 at 8:37
2
so how is getconf found?
– Joshua
Jan 13 at 15:03
@MukeshSaiKumar a stand-alone ‘cd’ command cannot ever work
– OrangeDog
Jan 13 at 17:03
Well, it'll "work" only for a value of working that, say, tests whether you can change to a directory, but doesn't actually leave the process that called it there. That's more functionality than none at all, though.
– Charles Duffy
Jan 13 at 17:05
 |Â
show 1 more comment
up vote
21
down vote
up vote
21
down vote
POSIX only mandates the /dev and /tmp directories to exist, and the /dev/null, /dev/tty, and /dev/console files. The standard utilities must exist, but there is no particular location specified. There may not be a /bin at all, and if there is it may not contain a sh, and if it does that may not be a POSIX sh.
You can get a valid PATH variable that includes the POSIX tools, including sh, with the getconf command:
$ PATH=$(getconf PATH)
$ sh
This can be useful on, for example, Solaris, where the default sh is not POSIX-compatible, but a compliant sh is provided and accessible in that way (because Solaris is a certified Unix). getconf PATH will include /usr/xpg4/bin at the front, which contains POSIX sh and a number of other required tools (including useless ones like cd).
answered Jan 13 at 2:25
Michael Homer
42.5k6108148
POSIX only mandates the /dev and /tmp directories to exist, and the /dev/null, /dev/tty, and /dev/console files. The standard utilities must exist, but there is no particular location specified. There may not be a /bin at all, and if there is it may not contain a sh, and if it does that may not be a POSIX sh.
You can get a valid PATH variable that includes the POSIX tools, including sh, with the getconf command:
$ PATH=$(getconf PATH)
$ sh
This can be useful on, for example, Solaris, where the default sh is not POSIX-compatible, but a compliant sh is provided and accessible in that way (because Solaris is a certified Unix). getconf PATH will include /usr/xpg4/bin at the front, which contains POSIX sh and a number of other required tools (including useless ones like cd).
answered Jan 13 at 2:25
Michael Homer
42.5k6108148
answered Jan 13 at 2:25
Michael Homer
42.5k6108148
answered Jan 13 at 2:25
Michael Homer
42.5k6108148
answered Jan 13 at 2:25
Michael Homer
42.5k6108148
42.5k6108148
Re Solaris: ...unless you're running a Solaris "small server" installation, which omits many of the POSIX tools. See unix.stackexchange.com/q/360359/135943
– Wildcard
Jan 13 at 3:11
"Useless" ones? I'd rather call them redundant.
– Mukesh Sai Kumar
Jan 13 at 8:37
2
so how is getconf found?
– Joshua
Jan 13 at 15:03
@MukeshSaiKumar a stand-alone ‘cd’ command cannot ever work
– OrangeDog
Jan 13 at 17:03
Well, it'll "work" only for a value of working that, say, tests whether you can change to a directory, but doesn't actually leave the process that called it there. That's more functionality than none at all, though.
– Charles Duffy
Jan 13 at 17:05
 |Â
show 1 more comment
Re Solaris: ...unless you're running a Solaris "small server" installation, which omits many of the POSIX tools. See unix.stackexchange.com/q/360359/135943
– Wildcard
Jan 13 at 3:11
"Useless" ones? I'd rather call them redundant.
– Mukesh Sai Kumar
Jan 13 at 8:37
2
so how is getconf found?
– Joshua
Jan 13 at 15:03
@MukeshSaiKumar a stand-alone ‘cd’ command cannot ever work
– OrangeDog
Jan 13 at 17:03
Well, it'll "work" only for a value of working that, say, tests whether you can change to a directory, but doesn't actually leave the process that called it there. That's more functionality than none at all, though.
– Charles Duffy
Jan 13 at 17:05
Re Solaris: ...unless you're running a Solaris "small server" installation, which omits many of the POSIX tools. See unix.stackexchange.com/q/360359/135943
– Wildcard
Jan 13 at 3:11
Re Solaris: ...unless you're running a Solaris "small server" installation, which omits many of the POSIX tools. See unix.stackexchange.com/q/360359/135943
– Wildcard
Jan 13 at 3:11
"Useless" ones? I'd rather call them redundant.
– Mukesh Sai Kumar
Jan 13 at 8:37
"Useless" ones? I'd rather call them redundant.
– Mukesh Sai Kumar
Jan 13 at 8:37
2
2
so how is getconf found?
– Joshua
Jan 13 at 15:03
so how is getconf found?
– Joshua
Jan 13 at 15:03
@MukeshSaiKumar a stand-alone ‘cd’ command cannot ever work
– OrangeDog
Jan 13 at 17:03
@MukeshSaiKumar a stand-alone ‘cd’ command cannot ever work
– OrangeDog
Jan 13 at 17:03
Well, it'll "work" only for a value of working that, say, tests whether you can change to a directory, but doesn't actually leave the process that called it there. That's more functionality than none at all, though.
– Charles Duffy
Jan 13 at 17:05
Well, it'll "work" only for a value of working that, say, tests whether you can change to a directory, but doesn't actually leave the process that called it there. That's more functionality than none at all, though.
– Charles Duffy
Jan 13 at 17:05
 |Â
show 1 more comment
up vote
11
down vote
No, it is not required for sh to be in /bin. It explicitly cites /bin, /usr/bin, and /usr/xpg4/bin as possible locations. The POSIX spec only requires that sh be in the PATH.
The POSIX spec states:
Applications should note that the standard PATH to the shell cannot be
assumed to be either/bin/shor/usr/bin/sh, and should be determined
by interrogation of the PATH returned by getconf PATH, ensuring that
the returned pathname is an absolute pathname and not a shell
built-in.
For example, to determine the location of the standard sh utility:
command -v sh
On some implementations this might return:
/usr/xpg4/bin/sh
answered Jan 13 at 2:24
John1024
44.2k4100116
add a comment |Â
up vote
11
down vote
No, it is not required for sh to be in /bin. It explicitly cites /bin, /usr/bin, and /usr/xpg4/bin as possible locations. The POSIX spec only requires that sh be in the PATH.
The POSIX spec states:
Applications should note that the standard PATH to the shell cannot be
assumed to be either/bin/shor/usr/bin/sh, and should be determined
by interrogation of the PATH returned by getconf PATH, ensuring that
the returned pathname is an absolute pathname and not a shell
built-in.
For example, to determine the location of the standard sh utility:
command -v sh
On some implementations this might return:
/usr/xpg4/bin/sh
answered Jan 13 at 2:24
John1024
44.2k4100116
add a comment |Â
up vote
11
down vote
up vote
11
down vote
No, it is not required for sh to be in /bin. It explicitly cites /bin, /usr/bin, and /usr/xpg4/bin as possible locations. The POSIX spec only requires that sh be in the PATH.
The POSIX spec states:
Applications should note that the standard PATH to the shell cannot be
assumed to be either/bin/shor/usr/bin/sh, and should be determined
by interrogation of the PATH returned by getconf PATH, ensuring that
the returned pathname is an absolute pathname and not a shell
built-in.
For example, to determine the location of the standard sh utility:
command -v sh
On some implementations this might return:
/usr/xpg4/bin/sh
answered Jan 13 at 2:24
John1024
44.2k4100116
No, it is not required for sh to be in /bin. It explicitly cites /bin, /usr/bin, and /usr/xpg4/bin as possible locations. The POSIX spec only requires that sh be in the PATH.
The POSIX spec states:
Applications should note that the standard PATH to the shell cannot be
assumed to be either/bin/shor/usr/bin/sh, and should be determined
by interrogation of the PATH returned by getconf PATH, ensuring that
the returned pathname is an absolute pathname and not a shell
built-in.
For example, to determine the location of the standard sh utility:
command -v sh
On some implementations this might return:
/usr/xpg4/bin/sh
answered Jan 13 at 2:24
John1024
44.2k4100116
answered Jan 13 at 2:24
John1024
44.2k4100116
answered Jan 13 at 2:24
John1024
44.2k4100116
answered Jan 13 at 2:24
John1024
44.2k4100116
44.2k4100116
add a comment |Â
add a comment |Â
up vote
2
down vote
As others here have said, this is not strictly required for POSIX compliance.
But arguably compatibility with existing software is far more important (after all, the purpose of POSIX is to have certain things work on all conforming operating systems) and if an OS does not provide sh at /bin/sh, that will break some things.
Most obviously, scripts with #!/bin/sh rely on this path being standardized. This is not required to work; POSIX doesn't even require that #! lines are supported, although it mentions that such functionality is common:
Another way that some historical implementations handle shell scripts is by recognizing the first two bytes of the file as the character string "#!" and using the remainder of the first line of the file as the name of the command interpreter to execute.
But if that isn't supported, a lot of existing software will break or require additional work to port.
answered Jan 13 at 22:33
Ian D. Scott
1616
add a comment |Â
up vote
2
down vote
As others here have said, this is not strictly required for POSIX compliance.
But arguably compatibility with existing software is far more important (after all, the purpose of POSIX is to have certain things work on all conforming operating systems) and if an OS does not provide sh at /bin/sh, that will break some things.
Most obviously, scripts with #!/bin/sh rely on this path being standardized. This is not required to work; POSIX doesn't even require that #! lines are supported, although it mentions that such functionality is common:
Another way that some historical implementations handle shell scripts is by recognizing the first two bytes of the file as the character string "#!" and using the remainder of the first line of the file as the name of the command interpreter to execute.
But if that isn't supported, a lot of existing software will break or require additional work to port.
answered Jan 13 at 22:33
Ian D. Scott
1616
add a comment |Â
up vote
2
down vote
up vote
2
down vote
As others here have said, this is not strictly required for POSIX compliance.
But arguably compatibility with existing software is far more important (after all, the purpose of POSIX is to have certain things work on all conforming operating systems) and if an OS does not provide sh at /bin/sh, that will break some things.
Most obviously, scripts with #!/bin/sh rely on this path being standardized. This is not required to work; POSIX doesn't even require that #! lines are supported, although it mentions that such functionality is common:
Another way that some historical implementations handle shell scripts is by recognizing the first two bytes of the file as the character string "#!" and using the remainder of the first line of the file as the name of the command interpreter to execute.
But if that isn't supported, a lot of existing software will break or require additional work to port.
answered Jan 13 at 22:33
Ian D. Scott
1616
As others here have said, this is not strictly required for POSIX compliance.
But arguably compatibility with existing software is far more important (after all, the purpose of POSIX is to have certain things work on all conforming operating systems) and if an OS does not provide sh at /bin/sh, that will break some things.
Most obviously, scripts with #!/bin/sh rely on this path being standardized. This is not required to work; POSIX doesn't even require that #! lines are supported, although it mentions that such functionality is common:
Another way that some historical implementations handle shell scripts is by recognizing the first two bytes of the file as the character string "#!" and using the remainder of the first line of the file as the name of the command interpreter to execute.
But if that isn't supported, a lot of existing software will break or require additional work to port.
answered Jan 13 at 22:33
Ian D. Scott
1616
edited Jan 13 at 23:57
answered Jan 13 at 22:33
Ian D. Scott
1616
answered Jan 13 at 22:33
Ian D. Scott
1616
answered Jan 13 at 22:33
Ian D. Scott
1616
1616
add a comment |Â
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%2f416725%2fdoes-sh-have-to-be-in-the-bin-directory%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
You can always use a symlink as
/bin/sh, in most cases on linux, it's already a symlink tobash. It's just that lots of scripts use hardcoded/bin/sh– cylgalad
Jan 13 at 9:11
5
Now that you have the answer that it can live anywhere it wants, you may ask yourself: how can you then portably write a shebang line for
sh? And the answer is: shebang isn't part of POSIX either, so the problem doesn't even present itself.– Jörg W Mittag
Jan 13 at 9:30
1
@JörgWMittag Yes, it's sometimes surprising how many of the things we think of as "standard" Unix features are not actually required by POSIX.
– Barmar
Jan 13 at 17:54
1
Whether or not you use a shebang is independent of whether the path
/bin/shmust exist on a POSIX system.– chepner
Jan 13 at 19:13
At least on Ubuntu-derived systems,
/bin/shis a link todash. On the BSDs,/bin/shis its not a link but a separate executable, and certainly notbash.– Rhialto
Jan 13 at 20:11