14

I'm connected to a remote shell and many keys aren't working properly such as arrows and the escape key. This answer Arrow keys, tab-complete not working suggested I might be in the wrong shell, so I referenced How to determine the current shell I'm working on?. Using the methods described, I get strange results.

echo $SHELL 
/bin/bash

but 

echo $0
sh

Which shell am I using?

Community
  • 1
Info5ek
  • 251

5 Answers5

15

Use proc filesystem to know shell's process name

When in doubt, use /proc file system. There's folders per each process, with comm file, where that process's command is described. So, knowing shell's PID, we can know what shell it is.

$ echo $$
4824
$ cat /proc/4824/comm                                                          
mksh
$ bash
xieerqi@eagle:~$ echo $$
6197
xieerqi@eagle:~$ cat /proc/6197/comm
bash

There's also other files that you can reference to extract that same info:

  • /proc/$$/stat
  • /proc/$$/status
  • /proc/$$/cmdline
  • /proc/$$/exe (symlink to the executable itself)

This may not work on older kernels or systems that don't support /proc filesystem ( Mac OS X, for instance ).

Variation on the same approach with ps command

ps command has -p flag which allows you to specify pid. We're still using the same idea of referencing the $$ variable for that.

$ ps -p $$                                                                     
  PID TTY          TIME CMD
 7728 pts/5    00:00:00 mksh
$ bash
xieerqi@eagle:~$ ps -p $$
  PID TTY          TIME CMD
 7776 pts/5    00:00:00 bash

$0 vs $SHELL.

According to Arch Wiki ,

SHELL contains the path to the user's preferred shell. Note that this is not necessarily the shell that is currently running, although Bash sets this variable on startup.

In other words, this is the users' default interactive shell, the same one that is set in /etc/passwd. This also is the reason why $SHELL variable doesn't change for subshells . For instance, no matter how many shells i spawn, $SHELL variable is unchanged:

$ echo $SHELL                                                                  
/bin/mksh
$ bash --posix
bash-4.3$ echo $SHELL
/bin/mksh
bash-4.3$ dash 
$ echo $SHELL
/bin/mksh

$0 argument will display the "self" - the command with which a program or name of the file. So a simple script like this:

#!/bin/bash
echo $0

Will give output like this:

$ ./test_script.sh                                                             
./test_script.sh

This is also apparent when you do something like this:

$ echo 'one two three' | xargs bash -c 'echo $0' 
one

For all shells , -c option places first command line argument into $0 variable.

As far as interactive shell goes, $0 usually would be sufficient, but as you can see, it is not reliable way to know what shell you're using. Knowing the process is far more reliable

Community
  • 1
Sergiy Kolodyazhnyy
  • 105,154
  • 20
  • 279
  • 497
  • echo $$ 5373 cat /proc/5373/comm cat: /proc/5373/comm: No such file or directory – Info5ek Sep 17 '16 at 20:40
  • So... you can shorten the command to just cat /proc/$$/comm? – edwinksl Sep 17 '16 at 20:41
  • @edwinksl actually . . . yeah . . . It's far simpler that way – Sergiy Kolodyazhnyy Sep 17 '16 at 20:42
  • cat /proc/$$/comm cat: /proc/5373/comm: No such file or directory. Could be failing because this shell could've been launched as a subprocess, which would explain why the the login shell is /bin/bash but I spawned into an sh session. – Info5ek Sep 17 '16 at 20:45
  • @user1800340 Do you have /proc directory ? Do ls /proc . Does it show output – Sergiy Kolodyazhnyy Sep 17 '16 at 20:45
  • @user1800340 nope, I've tested this way with multiple subshells, never failed me – Sergiy Kolodyazhnyy Sep 17 '16 at 20:46
  • cat: /proc/5373: Is a directory \n ls /proc/5373 attr... auxv... \n cat: /proc/5373/comm: No such file or directory – Info5ek Sep 17 '16 at 20:53
  • @user1800340 Are you using a virtual machine or this is regular install ? What kernel version this is ? Do uname -r – Sergiy Kolodyazhnyy Sep 17 '16 at 21:04
  • 1
    @user1800340 I've made a few edits to my answer, see if that helps you. It is apparent that you're not using Ubuntu , or at least not a recent version of it. – Sergiy Kolodyazhnyy Sep 17 '16 at 21:33
  • Thank you. I'm using VMWare on windows 10 to run a Debian distro (4.6.0-kali1-686-pae) and an Ubuntu distro (2.6.24-16-server). I'm using the Kali machine to connect to the Ubuntu machine. I did hear some things about this Ubuntu distro being out of date. This is partly by design as it's designed to be vulnerable to cyber attacks. I didn't realize the implications would be this bothersome. – Info5ek Sep 17 '16 at 22:06
  • 2
    @user1800340 That makes sense now and yes, you have 2.6 kernel there :) You probably can just use either stat file or ps version of the approach. If you're studying infosec , that's a good lesson for you - Linux evolves , systems change, and you have to keep open mind and choose attack vectors wisely – Sergiy Kolodyazhnyy Sep 17 '16 at 22:10
  • 2
    Oh wow, the Arch wiki is not just "not entirely correct", it's flat out wrong! The $SHELL variable has absolutely nothing to do with the shell you're currently running. It's just the default shell, as you say. It has absolutely no relation to the shell that's currently running. I've corrected the wiki. – terdon Sep 18 '16 at 10:15
11

You're using sh. Because $SHELL refers to the login shell, not the currently one being used.

Your provided StackOverflow question link has the correct method to correctly determine the currently running shell.

Community
  • 1
Anwar
  • 76,649
4

If the remote OS is Ubuntu (or another GNU/Linux based distribution), a very simple way to figure out what shell you are running is to run this command:

ls -l /proc/$$/exe

if the remote OS is not Ubuntu or at least a similar GNU/Linux distribution, you asked in the wrong site.

If for some reason the remote OS is missing /proc (e.g. running a stripped down, incomplete, or antique version of Ubuntu, or maybe a containerized OS instance) the above mentioned command won't work.

Looking to $0 will give you a clue it is not 100% reliable. Any program can fake its name to something else. In any case, it is very unlikely that you really run sh (the real Bourne shell) as it is almost never installed on Linux, you might be running an sh clone, likely dash.

jlliagre
  • 5,833
2

you seem to be currently using sh. To switch to bash you could just type "bash"

Edgy1
  • 537
1

There are already many great answers given, but you can also try issuing echo $BASH_VERSION. If this prints out a version number, you are in bash. If it outputs an empty line, you are inside some other shell.

Zoltan
  • 677