You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
try currently runs the intermediate temporary scripts that it creates using /bin/sh. This causes a problem if we want the internal script to run using a different shell and therefore inherit its state, e.g., bash functions.
I think that a good portable solution would be to run the intermediate scripts with whatever shell try is running too. What is a portable way to determine which shell we are running on? Here are some alternatives:
The $SHELL variable will contain the name of the login shell (it doesn't work if the subprocess is different than the login shell)
Using ps, e.g., ps -o args= -p "$$" or ps -o command= -p "$$". This seems to me like the most portable and correct solution.
Note that we don't really care about the underlying shell, we just want the executable (or even a link to it), so if try was invoked using /bin/sh we can just use that, we don't care that it was bash under the hood.
The text was updated successfully, but these errors were encountered:
I don't think the ps way is accurate enough, because it gives the name of the command that invoked the shell, but not the actual shell path. For example, if I execute a script with sh script I will get sh without a path, and won't know whether this is a link to, say, bash or sh. Here are the ways I recommend for commonly used systems.
For Linux I recommend using stat --format='%N' /proc/$$/exe, which will output something like '/proc/3339774/exe' -> '/bin/bash'
For FreeBSD I recommend using procstat -bh $$, which will output something like 78297 sh 1400073 /bin/sh (we need to use all fields after the third to take into account spaces in paths)
On macOS consider using lsof -p $$ -Fnf | sed -n '/^ftxt/{n;/dlyd/d;s/^n//;p;}' (The sed command prints the output of txt entries, removing the dynamic loader entry, which I've seen appear in older macOS versions).
try
currently runs the intermediate temporary scripts that it creates using/bin/sh
. This causes a problem if we want the internal script to run using a different shell and therefore inherit its state, e.g., bash functions.A running example of the wanted behavior follows:
I think that a good portable solution would be to run the intermediate scripts with whatever shell try is running too. What is a portable way to determine which shell we are running on? Here are some alternatives:
$SHELL
variable will contain the name of the login shell (it doesn't work if the subprocess is different than the login shell)ps
, e.g.,ps -o args= -p "$$"
orps -o command= -p "$$"
. This seems to me like the most portable and correct solution.Here are some SO posts that discuss this issue:
Note that we don't really care about the underlying shell, we just want the executable (or even a link to it), so if try was invoked using
/bin/sh
we can just use that, we don't care that it was bash under the hood.The text was updated successfully, but these errors were encountered: