See http://svn.eby-sarna.com/PEAK/INSTALL.txt?view=markup under the heading "SCRIPTS, BATCH FILES, AND '#!'":
invoke allows an arbitrary number of space-separated arguments to be passed to the command it invokes, thus working around various Unixes' #! parsing problems, as well as the "can't use a script as an interpreter" problem. It also searches the system PATH for the specified command. You may find this useful for non-PEAK script interpreters as well.
In short, you can use PEAK's "invoke" command (a simple C program) to work around this and various other cross-platform #! issues. PEAK has been doing executable config files for rather a long time, so we've run into this before.
It sounds like invoke works like /usr/bin/env does on FreeBSD (but not everywhere). That's nice; though the one issue I see is that /usr/bin/env is pre-installed into that exact location on most modern systems (and if it isn't, then the sysadmin should fix that, because it's a common idiom). If I can live with env's lowest-common denominator (which maybe I can), then it seems preferable. I already support moving the server argument into the main configuration file, so if exe isn't necessary then I should be set.
Incidentally, I probably thought about adding this feature of executable configuration files to paster because I'd seen it PEAK.# Ian Bicking
It's not env that's the problem. It's the operating system. Linux is passing only one argument to env, so even if you used the exact same env program, it would make no difference.
Then env should have fixed that by splitting the arguments itself! Especially since the env installed by the system should already be customized for the system (and whatever flaws it might have).# Ian Bicking
Um, no. That's not what env is even for. Env is a command to "run a program in a modified environment". The fact that env is often used in #! lines as a convenient hack to make #! pay attention to PATH has nothing to do with env's specified and intended behavior. If env were to do what you're suggesting, it would be violating its own documentation and the normal argument processing conventions for Unix commands. See also "man env".