Open angelhof opened 1 year ago
@mgree and @dspinellis any thoughts? I can implement the ps
solution, I just need a second opinion on whether it is adequately portable :)
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.
stat --format='%N' /proc/$$/exe
, which will output something like '/proc/3339774/exe' -> '/bin/bash'
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)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).I agree that ps
doesn't quite cut it. These detection approaches seem good; we should also have a flag that lets you pick the shell that runs.
Also: these APIs only exist on Linux and FreeBSD, so we don't need to worry about macOS portability.
@mgree which APIs do you speak of? Are you referring to the APIs exposed by try
or APIs to detect the shell path?
I'm talking about unshare
.
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.