> "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 car
"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
nd 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
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 b
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 f
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 i
> "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! Ca
>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 ve
>That's a fine answer, but a completely different concern.
Sorry, you are correct. I looked up the RFC (there are getting to be so many
I cannot trust memory any more).
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 bef
>>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 dev
>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 develop
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
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.
>
> N
>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.
But Perl is not an interactive shell! Can you imagine if a C
compiler allowed arbitrary amounts of text to be pre-inc
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> How are you going to enable strict in an unrelated lexical scope?
TC> Why are you using -w instead of use warnings, and can you just imagine the
TC> howling? This would surely kill your system.
like i said, i wasn't sure of
>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 u
>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.
>>
>>
> "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 cod
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
>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
> "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 t
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
>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
> "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
>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 "u
On Fri, Sep 01, 2000 at 08:46:50PM -, Perl6 RFC Librarian wrote:
> 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 pytho
On Fri, Sep 01, 2000 at 03:13:04PM -0600, Tom Christiansen wrote:
> 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
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
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
29 matches
Mail list logo
