[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