Skip to main content
Commonmark migration
Source Link
  1. Quick and dirty (and possibly wrong):

    Quick and dirty (and possibly wrong):

    There is almost always an environment variable $SHELL that you can learn this from. There are some edge cases where this will fail, particularly if one interactive shell is used to launch another. Most recent shells also set a variable about themselves in the form of $BASH_VERSION or $ZSH_VERSION. I don't know that sh does this.

There is almost always an environment variable $SHELL that you can learn this from. There are some edge cases where this will fail, particularly if one interactive shell is used to launch another. Most recent shells also set a variable about themselves in the form of $BASH_VERSION or $ZSH_VERSION. I don't know that sh does this.

  1. A bit fancier:

    A bit fancier:

    Alternatively, most interactive shells will know what they are and give you some useful output to if you run something like echo $0. This appears to rely on about the same information as you would get if you ran ps -fp $$, which would retrieve the process data for the process that launched ps.

Alternatively, most interactive shells will know what they are and give you some useful output to if you run something like echo $0. This appears to rely on about the same information as you would get if you ran ps -fp $$, which would retrieve the process data for the process that launched ps.

  1. More robust:

    More robust:

    A way that might work for some shells and environments that don't have convenience things such as environment variables set would be to rip the data you want out of proc and figure out what the running executable path is actually pointing to using readlink -f /proc/$$/exe. This has the advantage of giving you information about what executable was lauched even if it was a symlink to something else, in which case the SHELL variable might be lieing to you.

A way that might work for some shells and environments that don't have convenience things such as environment variables set would be to rip the data you want out of proc and figure out what the running executable path is actually pointing to using readlink -f /proc/$$/exe. This has the advantage of giving you information about what executable was lauched even if it was a symlink to something else, in which case the SHELL variable might be lieing to you.

  1. Quick and dirty (and possibly wrong):

There is almost always an environment variable $SHELL that you can learn this from. There are some edge cases where this will fail, particularly if one interactive shell is used to launch another. Most recent shells also set a variable about themselves in the form of $BASH_VERSION or $ZSH_VERSION. I don't know that sh does this.

  1. A bit fancier:

Alternatively, most interactive shells will know what they are and give you some useful output to if you run something like echo $0. This appears to rely on about the same information as you would get if you ran ps -fp $$, which would retrieve the process data for the process that launched ps.

  1. More robust:

A way that might work for some shells and environments that don't have convenience things such as environment variables set would be to rip the data you want out of proc and figure out what the running executable path is actually pointing to using readlink -f /proc/$$/exe. This has the advantage of giving you information about what executable was lauched even if it was a symlink to something else, in which case the SHELL variable might be lieing to you.

  1. Quick and dirty (and possibly wrong):

    There is almost always an environment variable $SHELL that you can learn this from. There are some edge cases where this will fail, particularly if one interactive shell is used to launch another. Most recent shells also set a variable about themselves in the form of $BASH_VERSION or $ZSH_VERSION. I don't know that sh does this.

  2. A bit fancier:

    Alternatively, most interactive shells will know what they are and give you some useful output to if you run something like echo $0. This appears to rely on about the same information as you would get if you ran ps -fp $$, which would retrieve the process data for the process that launched ps.

  3. More robust:

    A way that might work for some shells and environments that don't have convenience things such as environment variables set would be to rip the data you want out of proc and figure out what the running executable path is actually pointing to using readlink -f /proc/$$/exe. This has the advantage of giving you information about what executable was lauched even if it was a symlink to something else, in which case the SHELL variable might be lieing to you.

added 21 characters in body
Source Link
Caleb
  • 71.9k
  • 19
  • 203
  • 232
  1. Quick and dirty (and possibly wrong):

There is almost always an environment variable $SHELL that you can learn this from. There are some edge cases where this will fail, particularly if one interactive shell is used to launch another. Most recent shells also set a variable about themselves in the form of $BASH_VERSION or $ZSH_VERSION. I don't know that sh does this.

  1. A bit fancier:

Alternatively, most interactive shells will know what they are and give you some useful output to if you run something like echo $0. This appears to rely on about the same information as you would get if you ran ps -fp $$, which would retrieve the process data for the process that launched ps.

  1. More robust:

A way that might work for some shells and environments that don't have convenience things such as environment variables set would be to rip the data you want out of proc and figure out what the running executable path is actually pointing to using readlink -f /proc/$$/exe. This has the advantage of giving you information about what executable was lauched even if it was a symlink to something else, in which case the SHELL variable might be lieing to you.

  1. Quick and dirty:

There is almost always an environment variable $SHELL that you can learn this from. There are some edge cases where this will fail, particularly if one interactive shell is used to launch another. Most recent shells also set a variable about themselves in the form of $BASH_VERSION or $ZSH_VERSION. I don't know that sh does this.

  1. A bit fancier:

Alternatively, most interactive shells will know what they are and give you some useful output to if you run something like echo $0. This appears to rely on about the same information as you would get if you ran ps -fp $$, which would retrieve the process data for the process that launched ps.

  1. More robust:

A way that might work for some shells and environments that don't have convenience things such as environment variables set would be to rip the data you want out of proc and figure out what the running executable path is actually pointing to using readlink -f /proc/$$/exe. This has the advantage of giving you information about what executable was lauched even if it was a symlink to something else, in which case the SHELL variable might be lieing to you.

  1. Quick and dirty (and possibly wrong):

There is almost always an environment variable $SHELL that you can learn this from. There are some edge cases where this will fail, particularly if one interactive shell is used to launch another. Most recent shells also set a variable about themselves in the form of $BASH_VERSION or $ZSH_VERSION. I don't know that sh does this.

  1. A bit fancier:

Alternatively, most interactive shells will know what they are and give you some useful output to if you run something like echo $0. This appears to rely on about the same information as you would get if you ran ps -fp $$, which would retrieve the process data for the process that launched ps.

  1. More robust:

A way that might work for some shells and environments that don't have convenience things such as environment variables set would be to rip the data you want out of proc and figure out what the running executable path is actually pointing to using readlink -f /proc/$$/exe. This has the advantage of giving you information about what executable was lauched even if it was a symlink to something else, in which case the SHELL variable might be lieing to you.

added 164 characters in body
Source Link
Caleb
  • 71.9k
  • 19
  • 203
  • 232
  1. Quick and dirty:

There is almost always an environment variable $SHELL that you can learn this from. There are some edge cases where this will fail, particularly if one interactive shell is used to launch another. Most recent shells also set a variable about themselves in the form of $BASH_VERSION or $ZSH_VERSION. I don't know that sh does this.

  1. A bit fancier:

Alternatively, most interactive shells will know what they are and give you some useful output to if you run something like echo $0. This appears to rely on about the same information as you would get if you ran ps -fp $$, which would retrieve the process data for the process that launched ps.

  1. More robust:

A way that might work for some shells and environments that don't have convenience things such as environment variables set would be to rip the data you want out of proc and figure out what the running executable path is actually pointing to using readlink -f /proc/$$/exe. This has the advantage of giving you information about what executable was lauched even if it was a symlink to something else, in which case the SHELL variable might be lieing to you.

There is almost always an environment variable $SHELL that you can learn this from. There are some edge cases where this will fail, particularly if one interactive shell is used to launch another. Most recent shells also set a variable about themselves in the form of $BASH_VERSION or $ZSH_VERSION. I don't know that sh does this.

Alternatively, most interactive shells will know what they are and give you some useful output to if you run something like echo $0. This appears to rely on about the same information as you would get if you ran ps -fp $$, which would retrieve the process data for the process that launched ps.

  1. Quick and dirty:

There is almost always an environment variable $SHELL that you can learn this from. There are some edge cases where this will fail, particularly if one interactive shell is used to launch another. Most recent shells also set a variable about themselves in the form of $BASH_VERSION or $ZSH_VERSION. I don't know that sh does this.

  1. A bit fancier:

Alternatively, most interactive shells will know what they are and give you some useful output to if you run something like echo $0. This appears to rely on about the same information as you would get if you ran ps -fp $$, which would retrieve the process data for the process that launched ps.

  1. More robust:

A way that might work for some shells and environments that don't have convenience things such as environment variables set would be to rip the data you want out of proc and figure out what the running executable path is actually pointing to using readlink -f /proc/$$/exe. This has the advantage of giving you information about what executable was lauched even if it was a symlink to something else, in which case the SHELL variable might be lieing to you.

added 164 characters in body
Source Link
Caleb
  • 71.9k
  • 19
  • 203
  • 232
Loading
Source Link
Caleb
  • 71.9k
  • 19
  • 203
  • 232
Loading