Re: RFC 114 (v2) Perl resource configuration
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: but that is the user's to set. PERL_PRELOAD TC is there for the user to unset. allows the admin to globally set (in the system shell rc file) the rc files that perl will load. TC And what sorts of things might the admin care to globally set? I actually might have found it useful as a way of avoiding a . ~/.profile in a crontab. A perl program would be externally customized based upon the machine/ user/whatver running it. A single 'executable' that can have itself configure. Yes, one could do it in the shell/program, but a simple 'standard' method might be worthwhile. use perlrc qw(:system :user); Though the range of options and settings are probably so vast that a single module capable of handling all scenerios would be so large and slow that all gains would be lost just in the invocation. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 114 (v2) Perl resource configuration
"Greg Rollins" [EMAIL PROTECTED] writes: Would the rc support module loading? In other words, a sysadmin might want to give access to certain Perl modules to his/her users, and not to other users. That's the only use I can think of for dynamic Perl config. BTW, it's not something I'm against, I'm just trying to find a way I could use it. But for this to work, the users must not have filesystem access to the installed modules (otherwise they'll just Cuse lib). In which case the whole point is moot. [...] -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 114 (v2) Perl resource configuration
Would the rc support module loading? In other words, a sysadmin might want to give access to certain Perl modules to his/her users, and not to other users. That's the only use I can think of for dynamic Perl config. BTW, it's not something I'm against, I'm just trying to find a way I could use it. Greg Rollins Sys Admin Communication Associates Inc. - Original Message - From: "Uri Guttman" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, September 01, 2000 6:42 PM Subject: Re: RFC 114 (v2) Perl resource configuration "TC" == Tom Christiansen [EMAIL PROTECTED] writes: i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. TC You've got PERL5OPT. but that is the user's to set. PERL_PRELOAD allows the admin to globally set (in the system shell rc file) the rc files that perl will load. it needs to be separate from the env vars the user might want to set. TC Heck, I bet you could do a cleverness with .perldb, too. :-) i don't want to go there. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 114 (v2) Perl resource configuration
Uri Guttman [EMAIL PROTECTED] writes: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: many systems allow for a global/local startup file for various reasons. i see a potential use of this in perl but i don't see the specific use yet. build it they will use it. TC But Perl is not an interactive shell! Can you imagine if a C TC compiler allowed arbitrary amounts of text to be pre-included and what about the proposals for an interactive perl? maybe they should support this. An interactive Perl can certainly read some options, just like a debugger. This is not specific to Perl, of course; GDB, for one example, also reads configuration files when loading. But that doesn't mean GCC reads a configuration file to tell it what type of C code the system administrator has decided to mandate! Configuration files for Cperl -d, an interactive Perl, Cperldl, and any other application written in Perl are a nice idea (one that TomC seems to support). This has nothing to do with wanting to configure the language itself. [...] -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 11:40:13PM -0400, Uri Guttman wrote: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: TC But Perl is not an interactive shell! Can you imagine if a C TC compiler allowed arbitrary amounts of text to be pre-included and what about the proposals for an interactive perl? maybe they should support this. That can be handled totally differently. Shell::Config or something. Similar to CPAN::Config. So the basic problem here, leaving all the minor problems aside, is we have no concrete use for this feature. There's been a few half-hearted attempts at things this might be useful for maybe, but it all boils down to "somebody will find it useful to do something somewhere." I'd suggest we put a hold on further discussion about caveats and implementations until someone really justifies this thing. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Plus I remember being impressed with Ada because you could write an infinite loop without a faked up condition. The idea being that in Ada the typical infinite loop would be normally be terminated by detonation. -- Larry Wall in [EMAIL PROTECTED]
Re: RFC 114 (v2) Perl resource configuration
On Fri, 1 Sep 2000, Tom Christiansen wrote: it can be used for system specific @INC paths without recompiling perl That's what PERL5LIB is for. PERL5LIB is available for the individual user to use, set, unset, change, etc., at will. As sysadmin, you can't set it in /etc/profile and be sure that your setting will stick. Actually, you can't even guarantee that every process will be run under a shell that sources /etc/profile or indeed under a "shell" that sources any configuration file at all under /etc. Even if you could, however, there's still a maintenance issue. For "configuring" one package, perl, does it really make administrative sense to have to maintain N /etc/*profile files (one for each possible shell?) This would mean that every shell upgrade could potentially require manual intervention to retain the perl customization. If (please note I said "If" here--I'm not arguing for or against the proposal) it would be useful to configure perl, then I strongly would argue that such configuration ought to be localized to just a very few files under perl's control. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 114 (v2) Perl resource configuration
Can't you do this with with an environment setting? Shell people seem to think this a normal notion, but it's caused horrible security flaws in the past. And I couldn't imagine it of a C compiler, so I don't know why you would do this one. --tom
Re: RFC 114 (v2) Perl resource configuration
Forcing -w on Makes one-liners annoying. Makes running existing programs annoying. We have PERL5OPT You forgot the con that we've supposed to be "use warnings"-ing now. --tom
Re: RFC 114 (v2) Perl resource configuration
"MGS" == Michael G Schwern [EMAIL PROTECTED] writes: MGS Here's a little pros/cons list running through my head right now... MGS pro con MGS Customize @INC We have PERL5LIB MGS Forcing -T on Will break most existing programs. MGS Makes one-liners annoying. who runs one liners with -T? what about making the rc files load only if there is code not in a -e string? this solves the one liner problem. you can force them with another option if you want them with -e. i can't imagine why you would but there are crazies everywhere. MGS Furthermore, .perlrc files can currently be implemented without a core MGS patch. Write a script which looks for a .perlrc file, generates a bit MGS of perl code, prefixes this to the program being run and then passes MGS it all to perl. Put that in place of /usr/bin/perl and tada! We MGS could develop such a script and distribute it with Perl. Such a MGS script also makes a good prototype, to hash out the pros and cons of MGS this RFC should anyone want to go forward with it. yechhh!! and that script will slow everything down with a double call to perl. i think a system rc file is a good idea but the way to use it is not well defined. i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. export PERL_PRELOAD=/etc/sysperl:/home/uri/.perlrc perl foo simple, out of the way if you don't need it. on any site where the admins like to control stuff this way, they already preset many env values for you in the shared shell startup files. adding one more value would be trivial. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 114 (v2) Perl resource configuration
i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. You've got PERL5OPT. Heck, I bet you could do a cleverness with .perldb, too. :-) --tom
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 07:16:13PM -0400, Uri Guttman wrote: "MGS" == Michael G Schwern [EMAIL PROTECTED] writes: MGS Forcing -T on Will break most existing programs. MGS Makes one-liners annoying. who runs one liners with -T? That's the point. .perlrc would effect all perl, including one-liners. What's good for big programs is not good for small. what about making the rc files load only if there is code not in a -e string? this solves the one liner problem. I thought of this, but the special cases begin to pile up. First, there's the issue of Perl acting differently from a file as from a command line. Weird. Then in the .perlrc there's something things you'll want for one-liners, some for files, some for both. Sounds like it would make writing the .perlrc files hairy. And there's still the problem of .perlrc not being down with OPP (Other People's Perl). yechhh!! and that script will slow everything down with a double call to perl. Not necessarily. It could eval() instead. A prototype can be written and performace testing performed before we start declaring things slow. It will probably slow things down a bit, yes, but that has to be weighed against the *signifcantly* simpler implemetation than a core patch. Especially considering the low urgency of this RFC. i think a system rc file is a good idea but the way to use it is not well defined. i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. The question still remains unanswered. What do you DO with a .perlrc file?? -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse I am not one of those stupid moron who don't know what I am doing. I know about FDA. FDA raids hundreds of small businesses every year that deal with alternative medicine or therapy. They take away your computer, seize your $200,000 inventory, and drive your company totally out of business in no time if they ever approach you. --Alex Chiu, Immortality Guy
Re: RFC 114 (v2) Perl resource configuration
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. TC You've got PERL5OPT. but that is the user's to set. PERL_PRELOAD allows the admin to globally set (in the system shell rc file) the rc files that perl will load. it needs to be separate from the env vars the user might want to set. TC Heck, I bet you could do a cleverness with .perldb, too. :-) i don't want to go there. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 114 (v2) Perl resource configuration
but that is the user's to set. PERL_PRELOAD is there for the user to unset. allows the admin to globally set (in the system shell rc file) the rc files that perl will load. And what sorts of things might the admin care to globally set? --tom
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. TC You've got PERL5OPT. but that is the user's to set. PERL_PRELOAD allows the admin to globally set (in the system shell rc file) the rc files that perl will load. Like any other environment variable which the admin wants to be everywhere, put it in /etc/profile. A well configured system will handle it from there. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse BOFH excuse #405: Sysadmins unavailable because they are in a meeting talking about why they are unavailable so much.
Re: RFC 114 (v2) Perl resource configuration
"MGS" == Michael G Schwern [EMAIL PROTECTED] writes: who runs one liners with -T? MGS That's the point. .perlrc would effect all perl, including MGS one-liners. What's good for big programs is not good for small. what about making the rc files load only if there is code not in a -e string? this solves the one liner problem. MGS I thought of this, but the special cases begin to pile up. First, MGS there's the issue of Perl acting differently from a file as from a MGS command line. Weird. Then in the .perlrc there's something things MGS you'll want for one-liners, some for files, some for both. Sounds MGS like it would make writing the .perlrc files hairy. well, special cases are perl's middle name. i know we want to lower then for 6 but this makes some sense. i don't want any preloaded stuff for my one liners. if i did, i would add the -R (or whatever) option to force them. as for the special case, it is easy to see the source is from -e and it won't slow anything down. i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. MGS The question still remains unanswered. What do you DO with a MGS .perlrc file?? i wasn't trying to answer that, just come up with a clean way to support this feature. i don't know of a reason for me to use it but i am sure it will be used. it can be used for system specific @INC paths without recompiling perl, enforcing strict/-w/-T on all scripts, etc. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: i think an environment var might be a good way. if it is set, it is the file(s) to preload before running your code. TC You've got PERL5OPT. but that is the user's to set. PERL_PRELOAD allows the admin to globally set (in the system shell rc file) the rc files that perl will load. Like any other environment variable which the admin wants to be everywhere, put it in /etc/profile. A well configured system will handle it from there. Not all shells -- nor shell invocations -- attend to that file. A shell is ``privileged'' if the -p option is used or if the real user ID or group ID does not match the effective user ID or group ID (see getu- id(2) and getgid(2)). A privileged shell does not process $HOME/.profile nor the ENV parameter (see below). Instead, the file /etc/suid_profile is processed. Clearing the privileged option causes the shell to set its ef- fective user ID (group ID) to its real user ID (group ID). If the basename of the name the shell is called with (i.e., argv[0]) starts with `-' or if the -l option is used, the shell is assumed to be a login shell and the shell reads and executes the contents of /etc/profile and $HOME/.profile if they exist and are readable. This is clearly for login shells only; that is, interactive work. Which is what .perldb does. :-) But still, I'm not clear on what to do with it. --tom
Re: RFC 114 (v2) Perl resource configuration
it can be used for system specific @INC paths without recompiling perl That's what PERL5LIB is for. enforcing strict/-w/-T on all scripts, etc. How are you going to enable -T from this file you're going to eval? How are you going to enable strict in an unrelated lexical scope? Why are you using -w instead of use warnings, and can you just imagine the howling? This would surely kill your system. --tom
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 05:49:05PM -0600, Tom Christiansen wrote: On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote: Like any other environment variable which the admin wants to be everywhere, put it in /etc/profile. A well configured system will handle it from there. Not all shells -- nor shell invocations -- attend to that file. Yeah, well, that's not my problem that people don't use the One True Shell. ;) Actually, there is a utility out there for universal shell configuration. I've forgotten what its called, though. :( -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse BOFH excuse #116: the real ttys became pseudo ttys and vice-versa.
Re: RFC 114 (v2) Perl resource configuration
On Fri, Sep 01, 2000 at 05:50:52PM -0600, Tom Christiansen wrote: Why are you using -w instead of use warnings, and can you just imagine the howling? This would surely kill your system. Okay, okay, okay. You're the nth person that brought that up. Yes, "use warnings" makes more sense than -w. Same general problems all 'round. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse MORONS!
RE: RFC 114 (v2) Perl resource configuration
I entreat you to explain to me *anything* that you'd want to tweak with this that you already can't do right now. When I need to move Perl files from a default location to a new one. For example messing with @INC (and its like). THis could be used for example on a machine that has both development and production work going on.
Re: RFC 114 (v2) Perl resource configuration
I entreat you to explain to me *anything* that you'd want to tweak with this that you already can't do right now. When I need to move Perl files from a default location to a new one. For example messing with @INC (and its like). THis could be used for example on a machine that has both development and production work going on. That's a fine answer, but a completely different concern. @INC is trival. "And its like" are things you'll never get at! Look at the paths in Config. A trivial grep produces these, at least some of which I'm sure you want to change. You can't. Why not? Various reasons, but the most salient one is that they are not tweakable from Perl itself. And even if they were, they're wedged into a zillion different places--such as, just to name one example, the #! lines that head what gets stuck in scriptdir. --tom archlibexp='/usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd' ccflags='-fno-strict-aliasing -I/usr/local/include' cppflags='-fno-strict-aliasing -I/usr/local/include' dynamic_ext='B ByteLoader DB_File Data/Dumper Devel/DProf Devel/Peek Fcntl File/Glob GDBM_File IO IPC/SysV NDBM_File ODBM_File Opcode POSIX SDBM_File Socket Sys/Hostname Sys/Syslog attrs re' extensions='B ByteLoader DB_File Data/Dumper Devel/DProf Devel/Peek Fcntl File/Glob GDBM_File IO IPC/SysV NDBM_File ODBM_File Opcode POSIX SDBM_File Socket Sys/Hostname Sys/Syslog attrs re Errno' installarchlib='/usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd' installprivlib='/usr/local/lib/perl5/5.6.0' libpth='/usr/local/lib /usr/lib' prefix='/usr/local' privlibexp='/usr/local/lib/perl5/5.6.0' startsh='#!/bin/sh' aphostname='/bin/hostname' archlib='/usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd' bin='/usr/local/bin' binexp='/usr/local/bin' config_arg0='./Configure' full_ar='/usr/bin/ar' full_csh='/bin/csh' full_sed='/usr/bin/sed' glibpth='/usr/shlib /usr/lib/large /lib /usr/lib /usr/lib/386 /lib/386 /lib/large /usr/lib/small /lib/small /usr/ccs/lib /usr/ucblib /usr/local/lib ' groupcat='cat /etc/group' hostcat='cat /etc/hosts' inc_version_list='5.00554/OpenBSD.i386-openbsd 5.00554 5.005/OpenBSD.i386-openbsd 5.005' inc_version_list_init='"5.00554/OpenBSD.i386-openbsd","5.00554","5.005/OpenBSD.i386-openbsd","5.005",0' installbin='/usr/local/bin' installman1dir='/usr/local/man/man1' installman3dir='/usr/local/man/man3' installprefix='/usr/local' installprefixexp='/usr/local' installscript='/usr/local/bin' installsitearch='/usr/local/lib/perl5/site_perl/5.6.0/OpenBSD.i386-openbsd' installsitebin='/usr/local/bin' installsitelib='/usr/local/lib/perl5/site_perl/5.6.0' installstyle='lib/perl5' known_extensions='B ByteLoader DB_File Data/Dumper Devel/DProf Devel/Peek Fcntl File/Glob GDBM_File IO IPC/SysV NDBM_File ODBM_File Opcode POSIX SDBM_File Socket Sys/Hostname Sys/Syslog Thread attrs re' lddlflags='-Bshareable -L/usr/local/lib' ldflags=' -L/usr/local/lib' libc='/usr/lib/libc.so.23.1' libsdirs=' /usr/local/lib /usr/lib' libsfound=' /usr/local/lib/libgdbm.a /usr/lib/libm.a /usr/lib/libc.a' libspath=' /usr/local/lib /usr/lib' lns='/bin/ln -s' locincpth='/usr/local/include /opt/local/include /usr/gnu/include /opt/gnu/include /usr/GNU/include /opt/GNU/include' loclibpth='/usr/local/lib /opt/local/lib /usr/gnu/lib /opt/gnu/lib /usr/GNU/lib /opt/GNU/lib' man1dir='/usr/local/man/man1' man1direxp='/usr/local/man/man1' man3dir='/usr/local/man/man3' man3direxp='/usr/local/man/man3' pager='/usr/bin/less' passcat='cat /etc/passwd' perl5='/usr/local/bin/perl' perlpath='/usr/local/bin/perl' prefixexp='/usr/local' privlib='/usr/local/lib/perl5/5.6.0' ranlib='/usr/bin/ranlib' scriptdir='/usr/local/bin' scriptdirexp='/usr/local/bin' sh='/bin/sh' sitearch='/usr/local/lib/perl5/site_perl/5.6.0/OpenBSD.i386-openbsd' sitearchexp='/usr/local/lib/perl5/site_perl/5.6.0/OpenBSD.i386-openbsd' sitebin='/usr/local/bin' sitebinexp='/usr/local/bin' sitelib='/usr/local/lib/perl5/site_perl/5.6.0' sitelib_stem='/usr/local/lib/perl5/site_perl' sitelibexp='/usr/local/lib/perl5/site_perl/5.6.0' siteprefix='/usr/local' siteprefixexp='/usr/local' src='/usr/local/src/perl-5.6.0' startperl='#!/usr/local/bin/perl' strings='/usr/include/string.h' sysman='/usr/share/man/man1' timeincl='/usr/include/sys/time.h ' usrinc='/usr/include' xlibpth='/usr/lib/386 /lib/386'
Re: RFC 114 (v2) Perl resource configuration
What I am thinking of is a file that, if present and sane (i.e. read-only root), would be involked by the interpreter just before the users script was parsed. Looking at your example of things in the config file, well some of those are the things I would like to be able to get at in the new version with this feature. Well, those are all things that are beyond the scope of what can be done with a little eval. And some are very difficult: they're interdependent, and sometimes already written out to disk somewhere or other. I do not see an RFC about the matter, but people certainly have requested to be able to have a "position independent" perl installation, one which they can just copy and move to random places and things still work. I do not know the status of that want. --tom
RFC 114 (v2) Perl resource configuration
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl resource configuration
=head1 VERSION
Maintainer: Jonathan Scott Duff [EMAIL PROTECTED]
Date: 16 Aug 2000
Last-Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 114
Status: Developing
=head1 ABSTRACT
Perl should provide a mechanism to have code automatically loaded from a
file upon interpreter startup.
=head1 DESCRIPTION
Many programs have so-called "resource configuration" files (at least
that's what I call them) that are loaded and executed upon program
startup. Some example programs that have this ability include bash,
mutt, and python. Perl should do something similar.
The first version of this RFC proposed two "rc" files: C/etc/perlrc and
C~/.perlrc [1]. However, the author of this RFC has decided that the
motivations behind C/etc/perlrc are misguided. If the administrator
of the system wishes to impose global behavior, he can and should do
so through the environment.
This RFC now proposes that Perl 6 support a single per-user "rc" file,
C~/.perlrc, that is loaded for each Perl program run by the user.
This file would simply be Perl code that is loaded and executed just as if
the following were at the top of each perl program executed by the user:
BEGIN { $_ = "$ENV{HOME}/.perlrc"; require if -e; }
Execution of the C~/.perlrc would not be the default behavior.
A command line switch would be needed to invoke the automatic loading.
For example:
#!/usr/bin/perl -r
# ~/.perlrc is now loaded
Thus the C~/.perlrc file could be used by the user to setup common
defaults such as diagnostics or stricture for all of his/her programs.
Also, if RFC 184 (interactive mode for perl) is adopted, it may be
desirable to automatically execute the contents of C~/.perlrc upon
entered an interactive session regardless of whether or not the
command line switch that triggers loading of C~/.perlrc was used.
Nathan Wiger [EMAIL PROTECTED] brought up the issue of packaging a perl
program and/or module that may rely on settings in the local C~/.perlrc
which could be radically different from the settings in the C~/.perlrc
on the client's side. It is suggested that a warning be emitted (if
warnings are turned on) when the programmer uses the command line option
to the the "rc file". How do the other programming languages that have an
"rc file" concept handle this problem (e.g., python)?
=head1 IMPLEMENTATION
An option would need to be added to explicitly make perl look for the
C~/.perlrc file. The author of this RFC tentatively suggests C-r.
=head1 MIGRATION
Only those programs that wish to take advantage of this feature need
translating from Perl5. This is best left to the programmer rather
than an automated translator.
=head1 NOTES
[1] Note that this RFC is couched in terms of a Unix-ish filesystem. Perl
should support the analogous concept for the other platforms on which
it compiles.
=head1 REFERENCES
Perl 5.6.0 Documentation
From the man page for python 1.6
bash documentation:
http://www.gnu.org/manual/bash/html_chapter/bashref_5.html#SEC61
The mutt man page: http://www.mutt.org/doc/man_page.html
RFC 184: Perl should support an interactive mode:
http://www.mail-archive.com/perl6-language@perl.org/msg02493.html
