[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"

[aidenn0]

Which is not guaranteed to be present. 'command -v' should work on any posix shell though.

[em500]

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

[contingencies]

Nah.

  $ which "$(echo $0)"
  which: illegal option -- b
  usage: which [-as] program ...

  $ echo $0
  -bash

OSX. True story.

[SAI_Peregrinus]

Only for POSIX shells.

fish: $(...) is not supported. In fish, please use '(echo)'. which "$(echo $0)" ^

;)

[0x0]

But you might have customized your PATH after your shell was executed? So this does not seem accurate.

[stbtrax]

the article is about finding the specific version and path

[imwally]

Yeah, it's a little meta. I was afraid that what I was trying to say wouldn't quite come across. It's why I mentioned "the shell I'm currently typing in" so many times.

[moonchild]

echo $0 will tell you the exact path if it was so executed as a login shell (or otherwise with a full path). If the shell was executed otherwise, then 'which $0' will tell you where it came from, because it must have come from $PATH.

[em500]

> If the shell was executed otherwise, then 'which $0' will tell you where it came from, because it must have come from $PATH.

Not true: you can be in a shell not in $PATH, and if you executed it from a relative path, which $0 will not find it if you cd to a different location.