In the Pyenv project, we've had a peculiar problem.

We are substituting python (and python*) with our Bash scripts ("shims") that select a Python executable to run at runtime.

Now, some users wish to use a special selection logic when a Python script is run as path/to/script.py. The problem is, this logic should NOT apply if the script is instead run as <python> path/to/script.py!

Is there a way to reliably distinguish these two cases?

I wasn't able to find anything: depending on the way command line arguments are formulated in the 2nd case, the exact same command line could be executed in both cases:
(the Bash script given is not a real shim, just a demonstration example to showcase what our logic sees and does)

$ cat python3 
echo "'$0'"
for a in "$@"; do
  echo "'$a'"
# need to do the detection here
exec python3 "$@"

$ cat t.py 
import sys

$ $PWD/t.py

$ $PWD/python3 $PWD/t.py 

Since shebang is a Linux kernel feature -- maybe it sets some indicator that this mechanism has been used?

We've considered requiring users to use a special shebang in their Python scripts that they wish to apply the special logic to, but that idea proved unpopular because it makes those scripts unportable.

  • 1
    Have a look at this one.
    – Quasímodo
    Commented Jul 3, 2021 at 14:52
  • @Quasímodo the linked question requires a special shebang that's not usable outside of Pyenv. We had such an idea but it proved unpopular with users because it makes scripts unportable. Commented Jul 3, 2021 at 15:08
  • Can you create a "launcher" script/binary (in python, compiled c, or whatever you choose) as an option? I.E., the launcher can be version agnostic in itself, and selects the appropriate python* interpreter to pass the rest of the script to. Doing this, you can also allow your end-users methods to pass additional information, such as in specially formatted comments in the first few lines, to give it any additional hints/directions.
    – C. M.
    Commented Jul 3, 2021 at 16:26
  • 1
    You might be interested in python-exec. I have no idea how much actual overlap there is with your use case, but I suspect they had to solve some of the same problems as you are facing. Commented Jul 4, 2021 at 2:29
  • @AustinHemmelgarn we've had that idea, too, and that's what we currently suggest as an alternative to the requested feature -- a plugin that allows to create a separate set of manually configured shims for select scripts. Commented Jul 4, 2021 at 7:41

1 Answer 1


Since shebang is a Linux kernel feature -- maybe it sets some indicator that this mechanism has been used?

Yes, it does. Linux sets the AT_EXECFN auxiliar vector entry to the path of the original executable. In C, you can do it with char *at_execfn = (char*)getauxval(AT_EXECFN), followed by stat(at_execfn), etc.

Getting it from bash is tricky, though. You can try unpacking the /proc/self/auxv and then looking through /proc/self/mem. Good luck with that ;-)

  • Well, that does it... If I use a C program equivalent instead of the Bash script, at_execfn is /home/vmuser/t.py in the 1st case and /home/vmuser/python3 in the 2nd. But then the question arises how to do this in other OSes. We officially support MacOS as well, it's BSD-based. Commented Jul 3, 2021 at 15:51
  • I'll check if MacOS has an equivalent to AT_EXECFN Commented Jul 3, 2021 at 15:54
  • You could check if among these: stackoverflow.com/questions/1023306/… some wouldn't work like AT_EXECFN (rather than falling back to OP's initial problem)?
    – A.B
    Commented Jul 3, 2021 at 16:21
  • @A.B no dice. Both _dyld_get_image_name and _NSGetExecutablePath give post-shebang name. Commented Jul 3, 2021 at 18:08
  • Asked about MacOS at SO: stackoverflow.com/questions/68238888/… Commented Jul 3, 2021 at 18:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .