Subject: Re: NetBSD master CVS tree commits
To: Todd Vierling <tv@pobox.com>
From: Nathan J Williams <nathanw@MIT.EDU>
List: current-users
Date: 12/14/1997 18:21:07
[moved from source-changes to current-users for purposes of keeping
noise down on source-changes]
: - should we change this to /usr/pkg/bin/perl?
This should be /usr/bin/perl to maintain maximumm compatibility. (If the
package version of perl doesn't create a symlink to the binary in
/usr/bin/perl, it's very broken.)
Um, no. /usr/bin shouldn't ever be touched by a package
installation. That is sacrosanct to the base operating system. We had
this argument; we're putting package-stuff in /usr/pkg. /usr/bin/perl
should *not* work unless we integrate perl into our source tree (and
for this purpose, pkgsrc doesn't count).
The problem that you're trying to address is that there's no
cross-system way to invoke non-standard interpreters. Filesystems are
hardly a standard namespace. You can get away with /bin/sh, /bin/csh,
/bin/cat, /usr/bin/awk, and maybe a couple of others across a
reasonable set of platforms, but for perl, tcl, expect, python, hugs,
and any of your other favorite interpreters you're stuck customizing
all the scripts you use.
The solution I see to this problem, long-term, is to extend
the kernel's and the shell's exec*() mechanisim to look up the string
after #! in a database and do some kind of mapping. A simple database
could have useful things like ("/usr/bin/perl" ->
"/usr/pkg/bin/perl"), or eventually some non-pathname mappings like
("-perl5" -> "/usr/pkg/bin/perl"), so that people can write "#!-perl5"
scripts and have them generally work. Conveniently, #!x, where x is
not /, is not generally useful, and can be co-opted to this purpose.
Some people earlier were discussing some kind of EXEC_OTHER
dispatch mechanisim to support directly running Java code; that
mechanisim could probably be adjusted to do this as well, by seeing
#!- and running the lookup-and-exec program.
- Nathan