what's the difference between /bin/zsh and /usr/bin/zsh? [duplicate]
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
This question already has an answer here:
zsh is in /usr/bin, but also in /bin, what is the difference?
5 answers
I saw the following in /etc/shells -
% cat /etc/shells
# /etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/bin/zsh
/usr/bin/zsh
I want to know if there is a difference betweem /usr/bin/zsh and /bin/zsh ?
I did chose /usr/bin/zsh as it has to be interactive login and CTE skills.
shell zsh configuration
marked as duplicate by jasonwryan, glenn jackman, DopeGhoti, derobert, don_crissti Jan 3 at 22:08
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |Â
up vote
0
down vote
favorite
This question already has an answer here:
zsh is in /usr/bin, but also in /bin, what is the difference?
5 answers
I saw the following in /etc/shells -
% cat /etc/shells
# /etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/bin/zsh
/usr/bin/zsh
I want to know if there is a difference betweem /usr/bin/zsh and /bin/zsh ?
I did chose /usr/bin/zsh as it has to be interactive login and CTE skills.
shell zsh configuration
marked as duplicate by jasonwryan, glenn jackman, DopeGhoti, derobert, don_crissti Jan 3 at 22:08
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Yeah the dup doesn't actually address why. The fact that its symlinked makes for good backward compatibility but then why list it in shells twice? Unless that is ALSO for backward compatibility and if so that should be explained in an answer. P.S. Nvm one of the answers in dup does address that although only a blanket statement and of course isn't the accepted answer.
â jdwolf
Jan 3 at 21:46
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
This question already has an answer here:
zsh is in /usr/bin, but also in /bin, what is the difference?
5 answers
I saw the following in /etc/shells -
% cat /etc/shells
# /etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/bin/zsh
/usr/bin/zsh
I want to know if there is a difference betweem /usr/bin/zsh and /bin/zsh ?
I did chose /usr/bin/zsh as it has to be interactive login and CTE skills.
shell zsh configuration
This question already has an answer here:
zsh is in /usr/bin, but also in /bin, what is the difference?
5 answers
I saw the following in /etc/shells -
% cat /etc/shells
# /etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/bin/zsh
/usr/bin/zsh
I want to know if there is a difference betweem /usr/bin/zsh and /bin/zsh ?
I did chose /usr/bin/zsh as it has to be interactive login and CTE skills.
This question already has an answer here:
zsh is in /usr/bin, but also in /bin, what is the difference?
5 answers
shell zsh configuration
edited Jan 4 at 1:24
asked Jan 3 at 21:23
shirish
3,28342273
3,28342273
marked as duplicate by jasonwryan, glenn jackman, DopeGhoti, derobert, don_crissti Jan 3 at 22:08
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by jasonwryan, glenn jackman, DopeGhoti, derobert, don_crissti Jan 3 at 22:08
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Yeah the dup doesn't actually address why. The fact that its symlinked makes for good backward compatibility but then why list it in shells twice? Unless that is ALSO for backward compatibility and if so that should be explained in an answer. P.S. Nvm one of the answers in dup does address that although only a blanket statement and of course isn't the accepted answer.
â jdwolf
Jan 3 at 21:46
add a comment |Â
Yeah the dup doesn't actually address why. The fact that its symlinked makes for good backward compatibility but then why list it in shells twice? Unless that is ALSO for backward compatibility and if so that should be explained in an answer. P.S. Nvm one of the answers in dup does address that although only a blanket statement and of course isn't the accepted answer.
â jdwolf
Jan 3 at 21:46
Yeah the dup doesn't actually address why. The fact that its symlinked makes for good backward compatibility but then why list it in shells twice? Unless that is ALSO for backward compatibility and if so that should be explained in an answer. P.S. Nvm one of the answers in dup does address that although only a blanket statement and of course isn't the accepted answer.
â jdwolf
Jan 3 at 21:46
Yeah the dup doesn't actually address why. The fact that its symlinked makes for good backward compatibility but then why list it in shells twice? Unless that is ALSO for backward compatibility and if so that should be explained in an answer. P.S. Nvm one of the answers in dup does address that although only a blanket statement and of course isn't the accepted answer.
â jdwolf
Jan 3 at 21:46
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
One of them is probably a link to the other...
Traditionally, shells (like bash
, csh
and zsh
) are located in /bin - because a shell is needed even in single user mode or other times when /usr may be unmounted (/usr is often on a separate partition and may even be mounted through the network - thus not readily available in singe user mode).
On the other hand, additional shells (than the default one/ones) aren't strictly needed in single user mode (unless root happens to use one of them), so it's natural to put such shells it in /usr/bin instead of /bin.
When you do place it in /usr/bin though, it's common to provide a symbolic link to it from /bin, as users tends to expect their shells to be directly under /bin (not that a link would help if /usr wasn't mounted).
So when compiling the list of available shells to choose from (/etc/shells), both the real executable and the link have been listed. You can use ls -l
to check what is the link and what is the executable.
+++
Both /bin/zsh
and /usr/bin/zsh
are explicitly added together (same if-fi block) in the postinst
(post-install) script for the zsh-package, using the add-shell
command:
From zsh_5.1.1-1ubuntu2_amd64.deb:/DEBIAN/postinst
#!/bin/sh
...
case "$1" in
(configure)
# if test -z "$2"; then
add-shell /bin/zsh
add-shell /usr/bin/zsh
# fi
...
Yeah but isn't the more pertinent point why is it being listed twice in shells? if its the distributions choice to use for example /usr/bin/zsh then it should only list that.
â jdwolf
Jan 3 at 21:43
@jdwolf edited my answer... Don't know why, but I found how...
â Baard Kopperud
Jan 3 at 22:01
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
One of them is probably a link to the other...
Traditionally, shells (like bash
, csh
and zsh
) are located in /bin - because a shell is needed even in single user mode or other times when /usr may be unmounted (/usr is often on a separate partition and may even be mounted through the network - thus not readily available in singe user mode).
On the other hand, additional shells (than the default one/ones) aren't strictly needed in single user mode (unless root happens to use one of them), so it's natural to put such shells it in /usr/bin instead of /bin.
When you do place it in /usr/bin though, it's common to provide a symbolic link to it from /bin, as users tends to expect their shells to be directly under /bin (not that a link would help if /usr wasn't mounted).
So when compiling the list of available shells to choose from (/etc/shells), both the real executable and the link have been listed. You can use ls -l
to check what is the link and what is the executable.
+++
Both /bin/zsh
and /usr/bin/zsh
are explicitly added together (same if-fi block) in the postinst
(post-install) script for the zsh-package, using the add-shell
command:
From zsh_5.1.1-1ubuntu2_amd64.deb:/DEBIAN/postinst
#!/bin/sh
...
case "$1" in
(configure)
# if test -z "$2"; then
add-shell /bin/zsh
add-shell /usr/bin/zsh
# fi
...
Yeah but isn't the more pertinent point why is it being listed twice in shells? if its the distributions choice to use for example /usr/bin/zsh then it should only list that.
â jdwolf
Jan 3 at 21:43
@jdwolf edited my answer... Don't know why, but I found how...
â Baard Kopperud
Jan 3 at 22:01
add a comment |Â
up vote
2
down vote
accepted
One of them is probably a link to the other...
Traditionally, shells (like bash
, csh
and zsh
) are located in /bin - because a shell is needed even in single user mode or other times when /usr may be unmounted (/usr is often on a separate partition and may even be mounted through the network - thus not readily available in singe user mode).
On the other hand, additional shells (than the default one/ones) aren't strictly needed in single user mode (unless root happens to use one of them), so it's natural to put such shells it in /usr/bin instead of /bin.
When you do place it in /usr/bin though, it's common to provide a symbolic link to it from /bin, as users tends to expect their shells to be directly under /bin (not that a link would help if /usr wasn't mounted).
So when compiling the list of available shells to choose from (/etc/shells), both the real executable and the link have been listed. You can use ls -l
to check what is the link and what is the executable.
+++
Both /bin/zsh
and /usr/bin/zsh
are explicitly added together (same if-fi block) in the postinst
(post-install) script for the zsh-package, using the add-shell
command:
From zsh_5.1.1-1ubuntu2_amd64.deb:/DEBIAN/postinst
#!/bin/sh
...
case "$1" in
(configure)
# if test -z "$2"; then
add-shell /bin/zsh
add-shell /usr/bin/zsh
# fi
...
Yeah but isn't the more pertinent point why is it being listed twice in shells? if its the distributions choice to use for example /usr/bin/zsh then it should only list that.
â jdwolf
Jan 3 at 21:43
@jdwolf edited my answer... Don't know why, but I found how...
â Baard Kopperud
Jan 3 at 22:01
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
One of them is probably a link to the other...
Traditionally, shells (like bash
, csh
and zsh
) are located in /bin - because a shell is needed even in single user mode or other times when /usr may be unmounted (/usr is often on a separate partition and may even be mounted through the network - thus not readily available in singe user mode).
On the other hand, additional shells (than the default one/ones) aren't strictly needed in single user mode (unless root happens to use one of them), so it's natural to put such shells it in /usr/bin instead of /bin.
When you do place it in /usr/bin though, it's common to provide a symbolic link to it from /bin, as users tends to expect their shells to be directly under /bin (not that a link would help if /usr wasn't mounted).
So when compiling the list of available shells to choose from (/etc/shells), both the real executable and the link have been listed. You can use ls -l
to check what is the link and what is the executable.
+++
Both /bin/zsh
and /usr/bin/zsh
are explicitly added together (same if-fi block) in the postinst
(post-install) script for the zsh-package, using the add-shell
command:
From zsh_5.1.1-1ubuntu2_amd64.deb:/DEBIAN/postinst
#!/bin/sh
...
case "$1" in
(configure)
# if test -z "$2"; then
add-shell /bin/zsh
add-shell /usr/bin/zsh
# fi
...
One of them is probably a link to the other...
Traditionally, shells (like bash
, csh
and zsh
) are located in /bin - because a shell is needed even in single user mode or other times when /usr may be unmounted (/usr is often on a separate partition and may even be mounted through the network - thus not readily available in singe user mode).
On the other hand, additional shells (than the default one/ones) aren't strictly needed in single user mode (unless root happens to use one of them), so it's natural to put such shells it in /usr/bin instead of /bin.
When you do place it in /usr/bin though, it's common to provide a symbolic link to it from /bin, as users tends to expect their shells to be directly under /bin (not that a link would help if /usr wasn't mounted).
So when compiling the list of available shells to choose from (/etc/shells), both the real executable and the link have been listed. You can use ls -l
to check what is the link and what is the executable.
+++
Both /bin/zsh
and /usr/bin/zsh
are explicitly added together (same if-fi block) in the postinst
(post-install) script for the zsh-package, using the add-shell
command:
From zsh_5.1.1-1ubuntu2_amd64.deb:/DEBIAN/postinst
#!/bin/sh
...
case "$1" in
(configure)
# if test -z "$2"; then
add-shell /bin/zsh
add-shell /usr/bin/zsh
# fi
...
edited Jan 3 at 22:00
answered Jan 3 at 21:43
Baard Kopperud
4,28832344
4,28832344
Yeah but isn't the more pertinent point why is it being listed twice in shells? if its the distributions choice to use for example /usr/bin/zsh then it should only list that.
â jdwolf
Jan 3 at 21:43
@jdwolf edited my answer... Don't know why, but I found how...
â Baard Kopperud
Jan 3 at 22:01
add a comment |Â
Yeah but isn't the more pertinent point why is it being listed twice in shells? if its the distributions choice to use for example /usr/bin/zsh then it should only list that.
â jdwolf
Jan 3 at 21:43
@jdwolf edited my answer... Don't know why, but I found how...
â Baard Kopperud
Jan 3 at 22:01
Yeah but isn't the more pertinent point why is it being listed twice in shells? if its the distributions choice to use for example /usr/bin/zsh then it should only list that.
â jdwolf
Jan 3 at 21:43
Yeah but isn't the more pertinent point why is it being listed twice in shells? if its the distributions choice to use for example /usr/bin/zsh then it should only list that.
â jdwolf
Jan 3 at 21:43
@jdwolf edited my answer... Don't know why, but I found how...
â Baard Kopperud
Jan 3 at 22:01
@jdwolf edited my answer... Don't know why, but I found how...
â Baard Kopperud
Jan 3 at 22:01
add a comment |Â
Yeah the dup doesn't actually address why. The fact that its symlinked makes for good backward compatibility but then why list it in shells twice? Unless that is ALSO for backward compatibility and if so that should be explained in an answer. P.S. Nvm one of the answers in dup does address that although only a blanket statement and of course isn't the accepted answer.
â jdwolf
Jan 3 at 21:46