8

The /etc/shells says it has zsh installed in /bin/zsh, but also in /usr/bin/zsh.

brgr@envy17:~$ cat /etc/shells 
# /etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/usr/bin/tmux
/usr/bin/screen
/bin/zsh        <--
/usr/bin/zsh    <--

Now, the internet suggests me to use the one from /usr/bin/.

My question is: why? What is the difference between these two and why is bash for example only intalled at one path (/bin/bash)?

brgr
  • 263
  • 5
    Check them out with readlink to see if and where do they link to; e.g. readlink -f /usr/bin/zsh and other one similarly. – plesiv Apr 04 '13 at 20:57

6 Answers6

12

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
zorlem
  • 625
10

One is probably a symlink (or hard link) to the other.....but they are the SAME file.

mdpc
  • 6,834
  • 4
    To check, use ls -l. If one is a link of the other, you'll see linkedName -> /path/targetName – kmort Apr 04 '13 at 21:09
  • 4
    @kmort That'll only check if its a symlink. For hardlink, in the ls -l output, you'll see a link count > 1, and if you stat them, the inode number will be the same. – derobert Apr 04 '13 at 21:18
  • @mdpc Suggest you add the info from kmort and my comments to your answer. – derobert Apr 04 '13 at 21:19
  • Actually, both of them are links to /bin/zsh4, what I think is the actual shell. Thanks to all for their answers! – brgr Apr 05 '13 at 16:50
  • @derobert For me the link count of both file is 1, but they share the inode number. How is that possible? (I checked that they are not symbolic links.) – Franklin Yu Apr 05 '20 at 20:03
  • 1
    @FranklinYu check to make sure there isn't a symlink further up the path (e.g., /bin to /usr/bin or vice versa). Other than that, which filesystem are you using? – derobert Apr 05 '20 at 21:04
  • @derobert Thank you very much! That’s indeed the case. /bin linked to /usr/bin like in Arch Linux and Fedora. – Franklin Yu Apr 06 '20 at 00:36
6

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)

user42825
  • 71
1
$ ls -li /bin/zsh /usr/bin/zsh
19401918 -rwxr-xr-x 1 root root 861568 Feb  4  2019 /bin/zsh
19401918 -rwxr-xr-x 1 root root 861568 Feb  4  2019 /usr/bin/zsh

Matching i-nodes means they are hard-linked.

user98761
  • 111
0

they may be the same (check file sizes with ls -l) or /bin/zsh may be an static linked version

in my debian jessie booth are the same but i could play with update-alternatives to make /bin/sh a link to /bin/zsh-static

in case my system is missing any zsh link dependency i would be able to login if my shell is /bin/zsh (if it is linked to /bin/zsh-static)

this practice is the norm on solaris systems, where /bin/ksh is a lightweight version of korn shell, where the heavy all-the-features version lives on /usr/bin/ksh

/usr/bin precedes /bin/ in the path so if you don't specify which one you want you get the better shell by default

gfa
  • 59
0

For compatibility reasons. Some scripts use /usr/bin others use /bin. Several distros wish to move everything to /usr/bin since there's not much point in having /sbin and /bin anymore. One of the exceptions is bash, since #!/bin/bash has been used in countless scripts over the last decades, so providing /bin/bash for compatibility, with a symlink, is a good solution for now.

Alexander
  • 9,850