Date: Thu, 9 May 2002 15:11:42 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: current@FreeBSD.ORG Subject: Re: The future of perl on FreeBSD Message-ID: <20020509151142.B1494@shell.gsinet.sittig.org> In-Reply-To: <p05111757b8ff754e754e@[128.113.24.47]>; from drosih@rpi.edu on Wed, May 08, 2002 at 09:03:17PM -0400 References: <20020508075543.A5E5838CC@overcee.wemm.org> <xzpsn52nv0e.fsf@flood.ping.uio.no> <p05111757b8ff754e754e@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 08, 2002 at 21:03 -0400, Garance A Drosihn wrote:
>
> One of the nice things about using a redirector program,
> though, is that it also allows the user a way to set which
> version of perl they want to use, even if multiple copies
> of perl are installed, and they can do it on a session-by-
> session basis. That's the reason we did it at RPI. The
> idea has proved to be very useful over the past nine years.
This sounds to me like a "conditional" mailwrapper(8). :)
Having an /etc/perlwrapper.conf and a perlwrapper installed in
/usr/bin/perl would enable the admin to point to the installed
version of perl (the core interpreter which came with the base
system, a fullblown version from ports with lots of libs, an
experimental version from the perl development tree, a customized
version from whatever source, who knows? who cares?).
BTW do I consider the '#!' notion important and wouldn't suggest
any approach where the perl interpreter isn't called by the name
"/usr/bin/perl".
Since perl is not as systemwidely unique as an MTA is, the next
step could be to support ~/.perlwrapper.conf so users can switch
to a different interpreter without changing their PATH or every
script or even bothering the admin and thus every other user on
the system.
In case the interpreter to be invoked should be changable at any
random invocation (is demand for this so strong or is it just
"nice to have"?) the approatch could be to support conditions or
sections in the perlwrapper.conf syntax. Imagine something like
this:
----- perlwrapper.conf -------------------------------------
# section specified in $PERLWRAPPER_SECTION is used,
# "perlbase" by default (if ^^^ is empty or unset)
[perlbase]
perl /usr/bin/miniperl
suidperl /bin/false
[perlport]
perl /usr/local/bin/perl
suidperl /usr/local/bin/suidperl
------------------------------------------------------------
This would allow a user to work by default with what the admin
suggests but still be able to switch to a different interpreter
by calling `env PERLWRAPPER_SECTION=perlport /path/to/script`.
Should sections and or conditions be too hard to support for their
gain (or deviation from the current mailer.conf(5) syntax be too
bad a thing for reasons of a uniform wrapper program) the search
path could be expanded if it's already not just one file but a path
to search: $PERLWRAPPER_CONF:~/.perlwrapper.conf;/etc/perlwrapper.conf.
To summarize: Copying current mailwrapper's functionality for a
perlwrapper executable allows to ship the FreeBSD base with a core
language interpreter called "miniperl" (I understand we already
have this one) while calling the interpreter "/usr/bin/perl" is
still given. This would be no different from the current state
but provides the infrastructure for later extensions:
Installing a perl port and adjusting /etc/perlwrapper.conf should
be easy for an admin who wishes to use a newer or bigger (more
complete in the Perl community's view) or simply a different
interpreter.
For more customization under the users' control there's still
the option of implementing the perlwrapper.conf search path or
supporting sections or conditions in the config file (while the
search path seems to be the more sensible and intuitive approach).
BTW will updates in the config file as well as search path
variables in login or boot scripts be caught by mergemaster.
Symlinks are too easily destroyed by upgrading a system. I feel
configuring a system by editing /etc files is the traditional UNIX
way and thus more transparent and portable (diffable, patchable,
easily archived, distributed and applied).
The cost of parsing a five line text file when handing a
programming language script to an interpreter(!) seems acceptable
to me. The cost of following a symlink seems to be identical to
exec(3)uting a configured command with a known name. There is
only the additional cost of looking up and reading the one config
file for the unmodified base version as it will be shipped (the
above miniperl scenario). Only when implementing the search path
there is an additional missing lookup should the user not have an
~/.perlwrapper.conf file (making it two lookups and one read in
total). <not too serious> This could be speedup by importing
DJB's cdb code or some other fast database and using
"${PERLWRAPPER_CONF}${0}" for the index when looking up the
program to execute. </not too serious>
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020509151142.B1494>