zsh is in /usr/bin, but also in /bin, what is the difference?
One is probably a symlink (or hard link) to the other.....but they are the SAME file.
The contents of /etc/shells
are more or less static and have nothing to do with the the presence of specific shells installed on a system.
The fact that there are two entries in your /etc/shells
means only that if a user has either /bin/zsh
or /usr/bin/zsh
specified as their shell in /etc/passwd
, both of them would be considered 'valid' by daemons that consult /etc/shells
(eg. most FTP daemons).
To see the first available zsh in your path ($PATH) you can use the which command like this:
which zsh
Or whereis, which displays more information (the binary, source, and manual page files for a command):
whereis zsh
When /bin/zsh
exists, the redundant existence of /usr/bin/zsh
has mostly the purpose of portability in the sense that you don't need to edit each and any scripts' shebang line, which, when using zsh
, will likely address /usr/bin/zsh
.
zsh
is not considered a standard software, but many and ever more people are using it, even hardcore system administrators. And that's why more distributions tend to place it in /bin/zsh
as well.
To come to the point: it is not a zsh
issue, but a feature that ought to guarantee to boot a Linux (or historically, Unix) system into a defined state.
/bin
is defined to reside in the root file system, while /usr/bin
is not.
For the latter (among others), options include to have it on another disk (partition) or even on another machine, and mounted via NFS or other networking means.
So when booting a system without network support, or in case the network goes down accidentally, or when a disk crashes or a file system is corrupted, or just booting into single user mode without mounting anything, the files in /bin
are still accessible.
The same applies to /lib
and /usr/lib
: in fact, anything beyond /usr
is considered to not be vital for the basic system (also X11 is usually found somewhere in the /usr
branch. And that's also the reason why root's $HOME is not /home/root
, since /home
is also considered to not reside in the root file system.
And if the system disk crashed? Or the root file system is corrupted? Well, then chances are that you can't even load the kernel...
Much of the above is not too critical for today's systems. NFS mounted /usr/*
file systems are unnecessary, since disk space is cheap and available in vast amounts.
Even OS images are installed to a separate /boot
file system in many installations, so that loading the kernel doesn't guarantee to be able to mount the root file system, but for that we have initrd
these days, which holds a working initial root file system for kernel startup (in which, in fact, zsh
will be missing in most cases).
It's also common practice to have a big root file system that includes the /usr
branch, which has some advantages when cloning installations.
So, the traditional considerations that led to the distinction of /bin
and /usr/bin
(and the like) are a bit out of date, but are still implemented in recent systems.
(this was more an aside, but these are the facts)