How to see what /bin/sh points to

问题:

I was reading about the differences between /bin/sh and /bin/bash and came across this interesting question/answer: here

I made a comment to the answer asking this same question in my title to which he replied with an updated answer:

How can you find out what /bin/sh points to on your system?

The complication is that /bin/sh could be a symbolic link or a hard link. If it's a symbolic link, a portable way to resolve it is:

> % file -h /bin/sh
> /bin/sh: symbolic link to bash 

If it's a hard link, try

> % find -L /bin -samefile /bin/sh 
> /bin/sh 
> /bin/bash

I tried this and had trouble so I thought I would make a separate question.

My results from the linked answer:

>file -h /bin/sh
>/bin/sh: executable (RISC System/6000) or object module

>find -L /bin -samefile /bin/sh
>find: bad option -samefile

What am I missing? I'm running AIX:

>oslevel -s
7100-03-03-1415

回答1:

If you need to programatically test if they are the same, you can use stat to query the inode of /bin/sh and compare with the inode of /bin/bash.

if [ $(stat -L -c %i /bin/sh) -eq $(stat -L -c %i /bin/bash) ]; then
    .....
fi

If you just need to see with your eyes if they are the same run the stat commands and see if they return the same inode number.

stat -L -c %i /bin/sh
stat -L -c %i /bin/bash

回答2:

Since you are only searching through bin anyway, you can bypass find entirely and just check if sh and bash are hard links to the same file:

test /bin/sh -ef /bin/bash

OR

[ /bin/sh -ef /bin/bash ]

This is not as reliable as running find on all the possibilities, but it's a good start. While AIX find doesn't support -samefile, it does support -exec, which can be combined with the command above to simulate the same functionality:

find -L /bin -exec test /bin/sh -ef '{}' ';'

回答3:

As the answer you commented on says, -samefile isn't a standard feature of find. Neither is -inum, which searches based on an explicitly given inode number. But if your find supports that, use it.

POSIX ls supports -i, which prints the inode numbers. If find doesn't have -inum, all you need to do is go through all plausible files /bin/sh could be a hard link with...

Though before that, you could check if the file even has any other hard links, ls -l is required to show the number of links:

$ ls -l /bin/bash
-rwxr-xr-x 1 root root 1029624 Nov  5 23:22 /bin/bash
           ^ here

Of course, there's no requirement for /bin/sh to be linked to anything. It could be just another program. (Or even an identical copy of some of other file, though I don't think that's very likely.)

回答4:

Check for GNU Bash

I'm going to answer your question in a different way, because it's actually simpler to find out if sh is GNU Bash (or something else that responds to a --version flag) than it is to chase inodes. There's also the edge case where the shell is renamed rather than linked, in which case mapping links won't really help you find an answer.

For example, to interrogate /bin/sh on macOS:

$ /bin/sh --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16)
Copyright (C) 2007 Free Software Foundation, Inc.

Alternatively, you can grep (or similar) for the string bash to capture the exit status. For example:

# Close stderr in case sh doesn't have a version flag.
if sh --version 2>&- | grep -qF bash; then
  echo "sh is bash"
else
  echo "sh isn't bash"
fi

Of course, /bin/sh could be some other shell besides bash or the original bourne shell, but that's outside the scope of your original question. However, many shells such as ksh and tcsh also support the version flag, so judicious use of a case statement could help you extend the test to determine exactly which shell binary /bin/sh really is.

回答5:

You can also do readlink -f /bin/sh. For me it points to /bin/dash.

回答6:

I can not really see the point of this exercise.

/bin/sh is a POSIX shell and bash has extensions to the POSIX standard that /bin/sh does not support.

If you are writing a POSIX shell script, use /bin/sh. If you are writing a bash shell script, use bash.

Do not try to write a bash script that will be executed with /bin/sh, and don't try to programatically try to determine the abilities of the current shell based on what /bin/sh (or the current interpreter) is linked to. Instead, make the script executable and use the correct #!-line for the script.