
What Shell Am I Using? - todsacerdoti
https://nil.wallyjones.com/what-shell-am-i-using/
======
ridiculous_fish
fish shell discovers its own filesystem path, and then looks for resources
(completions, functions, etc) relative to that path. You can move a fish
directory hierarchy to someplace else and it will still work.

One advantage is testing. To test fish, it first must be installed into a
directory tree, but relative paths are preferred over build-time paths, so
there is no special "build for test" mode. Also this makes it easier for fish
to invoke itself as part of a test.

A second advantage is embedding. GNU encourages supporting relocation [1], and
fish also provides a Mac app which can be run from anywhere, no installation.

Anyways there's a lot of benefits if a shell can find itself.

1:
[https://www.gnu.org/software/gnulib/manual/html_node/Support...](https://www.gnu.org/software/gnulib/manual/html_node/Supporting-
Relocation.html)

------
joosters
For bash, the easiest way would be to just type help', which will report the
currently executing shell's version number (e.g. 'GNU bash, version
5.0.18(1)-release (x86_64-apple-darwin19.5.0)'

I'm not familiar with zsh, perhaps it also has some built-in commands that
would report the release version?

~~~
codetrotter

      % help
      zsh: command not found: help
    

Well, it kinda works. Just not in the way you might have hoped :P But the
output lets you know that you are running zsh.

And to find out the version:

    
    
      % echo $ZSH_VERSION
      5.7.1
    

(Assuming no-one has been silly and overridden the value of said environment
variable in their zshenv file or something. But if we assumed that to be
likely then we should also assume that someone using bash had aliased 'help'
to something else too, so I think it is fair to assume that no-one had done
that.)

~~~
sk0g
Fish opens up file:///usr/share/doc/fish/index.html in Firefox with the
following console output:

    
    
        ╰─>$ help
        
        (firefox:42227): Gtk-WARNING **: 11:46:58.100: Locale not supported by C library.
                Using the fallback 'C' locale

~~~
OrderlyTiamat
That looks like output from Firefox. The page itself should be the fish help
page.

~~~
sk0g
That's right, but the output of the help command doesn't provide any
indication as to what shell I'm running still.

------
bruce_one
`readlink -e /proc/$$/exe` would be a simple solution on linux -> /proc is
such a fun treasure trove of process info :-)

(Not sure it macOS has as much info in /proc?)

~~~
codetrotter
> Not sure it macOS has as much info in /proc?

macOS does not have procfs

~~~
msla
> macOS does not have procfs

[https://en.wikipedia.org/wiki/Procfs](https://en.wikipedia.org/wiki/Procfs)

It also got dropped from OpenBSD:

> It was removed from OpenBSD in version 5.7, which was released in May 2015,
> because it "always suffered from race conditions and is now unused".[2]

The OpenBSD people don't say what you should replace it with, but backing up
in the paragraph, the FreeBSD people do:

> As of February 2011, procfs is gradually becoming phased out in FreeBSD.[1]

Chasing that reference:

[https://lists.freebsd.org/pipermail/freebsd-
fs/2011-February...](https://lists.freebsd.org/pipermail/freebsd-
fs/2011-February/010760.html)

> Why is procfs deprecated in favor of procstat?

[snip]

> The security issues are long-standing and there have been many over the
> years, but the real reason is something that's less evident (or at least
> less directly apparent):

> Simply put, procfs on FreeBSD has been neglected. There isn't a lot of
> attention being given to it, and the only modifications in recent
> months/years have been generally minor compared to the rest of the tree. You
> can review some of the commits yourself:

>
> [http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/procfs/](http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/procfs/)

> Others like yourself have asked what the state of procfs is, going back as
> far as 2005. Be sure to read the reply as well:

> [http://unix.derkeiler.com/Mailing-
> Lists/FreeBSD/questions/20...](http://unix.derkeiler.com/Mailing-
> Lists/FreeBSD/questions/2005-05/2607.html)

Here's the FreeBSD procstat manpage:

[https://www.freebsd.org/cgi/man.cgi?procstat](https://www.freebsd.org/cgi/man.cgi?procstat)

Aside from bitrot, is there a reason to prefer procstat over procfs?

------
gorgoiler
Something I’ve never understood about Unix: what’s the point of the shell
field in passwd(5), /etc/shells and chsh(1) when one can just “exec /my/shell”
in a standard init file?

Is it a hangover from the days when mainframes charged $0.12 per command?

~~~
kristopolous
Let me introduce you to a few friends, only 3 for now. Hopefully these will
answer your question:

* nologin: [https://man7.org/linux/man-pages/man8/nologin.8.html](https://man7.org/linux/man-pages/man8/nologin.8.html)

* scponly: [https://linux.die.net/man/8/scponly](https://linux.die.net/man/8/scponly)

* git-shell: [https://git-scm.com/docs/git-shell](https://git-scm.com/docs/git-shell)

If your policy is instead to fire up a full blown unrestricted bash shell,
then hope the user doesn't exit your script before you swap it with a
restricted shell, I've got some surprises for you.

Even if you trust your users, every one of them is a potential doormat for a
malicious user to wipe their feet on as they use leaked credentials.

Moral of the story: the stuff is there for a reason and it's easy to use.
Might as well do it. Most of the vintage useless stuff is long gone, if it's
there it's probably still important.

------
slmjkdbtl
reminds me of the article about how to quit vim
[https://github.com/hakluke/how-to-exit-vim](https://github.com/hakluke/how-
to-exit-vim)

~~~
max_hammer
This made my morning. LoL

------
badrabbit
I would just pstree and see what the parent of pstree is. Or top/htop.

------
denvercoder904
I use 'echo $0' to see what shell I'm using.

~~~
jan6
which "$(echo $0)" should work no matter the invokation ;p if full path, it
still returns full path, if just "bash" or such it finds it from $PATH,
badoom!

~~~
xorcist
The only reason anyone would want to say "$($echo $0)", echoing the variable
through a subshell and substituting it with itself, is to rely on the subshell
parameter splitting to remove duplicate field separators from the variable.

That is likely not the case there, and any such file names are unlikely to
exist. Just say: which "$0"

------
1vuio0pswjnm7
On BSD, the approximate "lsof" equivalent, fstat, is part of the base system.
Does macOS not have fstat?

~~~
imwally
Apparently it does not:

    
    
       ~ % which fstat
       fstat not found

------
max_hammer
I use `ps -p "$$"`

------
raggi
plot twist: the binary was unlinked already

~~~
segfaultbuserr
A quick and dirty way to detect a modified executable on Linux, is to compare
/proc/$pid/exe and its target.

    
    
        $ readlink /proc/$$/exe
        /bin/bash (deleted)
    
        $ sha256sum /proc/$$/exe $(readlink /proc/$$/exe)
        16a94220a1cf204076640914f09cf0af59da07771819e7eb9671216643296d73  /proc/665119/exe
        16a94220a1cf204076640914f09cf0af59da07771819e7eb9671216643296d73  /bin/bash
        sha256sum: '(deleted)': No such file or directory
    

If the unlinked executable has been replaced by a new executable with the same
content, they will have the same checksum, this could possibly happen if the
package has been reinstalled, which is unlikely to occur. If the original
executable is nowhere to be found on the disk, at least you can...

    
    
        $ cp /proc/$$/exe  shell_bin_under_analysis
        
        $ strings shell_bin_under_analysis | grep version
        GNU bash, version %s-(%s)
        GNU bash, version %s (%s)
        License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
        @(#)Bash version 5.0.16(1) release GNU
    
        $ strings shell_bin_under_analysis | grep zsh
        # [...]
        zsh-5.8-0-g77d203f
        # [...]

~~~
m463
zsh doesn't use "what" strings? well there goes that idea.

------
reportgunner
> _that only told me the location of zsh the executable which is only correct
> because I added homebrew 's /usr/local/bin location to my PATH_

Eh, why not remove it from PATH then ?

~~~
em500
I think you're missing the point. The author wants to know the location of the
binary of the shell he's currently running. Changing PATH doesn't help
answering this question: it only changes what `which` displays, but the point
of the author is that `which` is not the correct tool to help answering this
question.

------
ashayh
This should also do it: realpath /proc/$$/exe

~~~
segfaultbuserr
+1. On Linux, with /proc, it's just much easier.

------
jan6
what happened to the simple invocation of `which "$(echo $0)"` ?

~~~
em500
As the author notes in the 2nd section, that will return the location of the
binary in the user path, which is not necessarily the one that is currently
running.

