you shouldn't be putting complex arguments in a shebang.
it's there to tell where the interpreter for the current file is.
shebang can't even handle more than a single argument on its own. if you have `#!/bin/program -args somescript`, it will divide it into ['/bin/program','-args somescript'], which is almost never what you actually wanted. ( this is linux specific, shebangs aren't necessarily universally portable between all unices )
if you want to do something complex, make it `#!/bin/sh` and then `exec` from the current file with whatever arguments you need.
one thing that link doesn't mention is that you can use env to lookup an interpreter via the current path.
`#!/usr/bin/env python3` for example, will find whatever `python3` the users is using, without having to know where it is.
this can be useful for scripts that you will be running from virtual environments, for example, which work by overriding the PATH to the python interpreter.
you wouldn't want to do this with anything installed, however, since you wouldn't want installed programs to let the user control what interpreter to use. instead, you should just use an absolute path.
there is an option in env, -S, that can be used to parse a command line from a single string specifically to handle this limitation.
after years of avoiding much trickery in shebang lines, it seems like a questionable practice at best.
I have always thought that shebangs are absolute paths to be weird. Everything else in my Linux day to day operates by traversing the PATH, why do shebangs get to be different?
the PATH search is done in userspace by the exec'ing process. the kernel doesn't have or care what the processes' environment PATH says. it just gets the final location.
shebang processing is the kernel peeking at the first couple hundred bytes of a file to see if it should execute it using some other file instead of running it directly. there isn't a userspace yet because it's still setting the process up. even if there was a userspace, PATH searching should be done for the `exec`ing process' path, not the PATH given to the new process. so you'd have to squirrel away the calling processes path somewhere on top of everything else.
so, it would be a pain. and also incompatible with all of the previous exec system calls, since if you "fixed" it to follow the path, anything not expecting that could break.
it's there to tell where the interpreter for the current file is.
shebang can't even handle more than a single argument on its own. if you have `#!/bin/program -args somescript`, it will divide it into ['/bin/program','-args somescript'], which is almost never what you actually wanted. ( this is linux specific, shebangs aren't necessarily universally portable between all unices )
if you want to do something complex, make it `#!/bin/sh` and then `exec` from the current file with whatever arguments you need.
one thing that link doesn't mention is that you can use env to lookup an interpreter via the current path.
`#!/usr/bin/env python3` for example, will find whatever `python3` the users is using, without having to know where it is.
this can be useful for scripts that you will be running from virtual environments, for example, which work by overriding the PATH to the python interpreter.
you wouldn't want to do this with anything installed, however, since you wouldn't want installed programs to let the user control what interpreter to use. instead, you should just use an absolute path.
there is an option in env, -S, that can be used to parse a command line from a single string specifically to handle this limitation.
after years of avoiding much trickery in shebang lines, it seems like a questionable practice at best.