Mailing List Archive

On Mon, 23 Oct 1995, Aaron Sherman wrote:

>
> I could really use the following for command-line hacks (like checking
> to see if some use of a library function is valid):
>
> env variable, "PERLMODS"
>
> Would be a space-separated list (or, whatever sep-char you
> wanted. Can't be ":"). Contains a list of modules that should be
> auto-used before parsing of the script. Why? Because for command-line
> work, listing 5 libraries takes up too much room, and when you want a
> quick one-liner to verify something, having to edit a file is a pain
> in the ass.
>
> -AJS
>
> PS: The other option is a "~/.perlrc" that would be checked if
> -<mumble> command-line flag was given, or if -e was used. In this way,
> you would always get the dot-file when you really want it, and would
> never get it from stand-alone scripts, where it could be a *bad
> thing*(tm). The problem is that it is just as much a pain to edit
> ~/.perlrc as to create the stand-alone prog. so I see people having a
> .perlrc that does the moral equiv of: "use $PERLLIB/*", which would
> make all startups seem verrry slllowwww....

Consider the danger of these... What if _you_ write the module, and the
script you are starting is suid root... This needs some thought. But look
at how DProf uses environment variables.

> --
> Aaron Sherman <ajs@ajs.com> B4 f w+ c kv s+(--)v r p
> I-Kinetics, Inc. Pager: (508)545-0584
> 1 NE Executive Park Fax: (617)270-4979
> Burlington, MA 01803-5005 WWW: http://ajs.com/~ajs/
> ajs@ajs.com or ajs@openmarket.com
> "I speak for no one."
>
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

>>>>> "Kenneth" == Kenneth Albanowski <kjahds@kjahds.com> writes:

Kenneth> On Mon, 23 Oct 1995, Aaron Sherman wrote:

Kenneth> Consider the danger of these... What if _you_ write the
Kenneth> module, and the script you are starting is suid root... This
Kenneth> needs some thought. But look at how DProf uses environment
Kenneth> variables.

Well, in my first example, you should never, ever, ever, ever use
PERLLIB or any other such env variable if running as a setuid
program. INC should be hand-set to the system default +
program-specific directories, and nothing else from the env should be
trusted by default. Given.

In my second example (command-line parameters), you don't have a
problem, because I suggested that -e would turn the parameter on, but
otherwise it is off by default. Thus a setuid (or non-setuid) script
would never look at the .perlrc.

-AJS

--
Aaron Sherman <ajs@ajs.com> B4 f w+ c kv s+(--)v r p
I-Kinetics, Inc. Pager: (508)545-0584
1 NE Executive Park Fax: (617)270-4979
Burlington, MA 01803-5005 WWW: http://ajs.com/~ajs/
ajs@ajs.com or ajs@openmarket.com
"I speak for no one."

On Mon, 23 Oct 1995, Aaron Sherman wrote:

> >>>>> "Kenneth" == Kenneth Albanowski <kjahds@kjahds.com> writes:
>
> Kenneth> On Mon, 23 Oct 1995, Aaron Sherman wrote:
>
> Kenneth> Consider the danger of these... What if _you_ write the
> Kenneth> module, and the script you are starting is suid root... This
> Kenneth> needs some thought. But look at how DProf uses environment
> Kenneth> variables.
>
> Well, in my first example, you should never, ever, ever, ever use
> PERLLIB or any other such env variable if running as a setuid
> program. INC should be hand-set to the system default +
> program-specific directories, and nothing else from the env should be
> trusted by default. Given.

Yes, given.

> In my second example (command-line parameters), you don't have a
> problem, because I suggested that -e would turn the parameter on, but
> otherwise it is off by default. Thus a setuid (or non-setuid) script
> would never look at the .perlrc.

Yeah, I missed that bit.

There is a different way of looking at this, though. Back a bit, Tim (?)
suggested a -m switch, so we could say "perl -man foo", and have the
"Auto::an" package invoked, which in turn would do a lookup on "foo" in
the manual. What if a similar facility was available, something like...
Hmm... not to many switches left... OK, let's use -b, for begin:

perl -bIO -e "$fh = new IO::Hanlde;#etc..."

Or

perl -bPOSIX,IO,Data::Dump -e "...";

setuid scripts would ignore -b, and perhaps it shouldn't be accepted if
you aren't using -e.

I see a rather useful addition to this idea, though: make -d work the
same way. Currently, to use DProf you need the rather inelegant:

PERL5DB="use Devel::DProf;" perl -d test.pl

How about giving -d an argument, so you can say:

perl -dDprof test.pl

and it will automatically C<use Debug::DProf> before the program runs, in
addition to turning on -d?

> -AJS
>
> --
> Aaron Sherman <ajs@ajs.com> B4 f w+ c kv s+(--)v r p
> I-Kinetics, Inc. Pager: (508)545-0584
> 1 NE Executive Park Fax: (617)270-4979
> Burlington, MA 01803-5005 WWW: http://ajs.com/~ajs/
> ajs@ajs.com or ajs@openmarket.com
> "I speak for no one."
>
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

You mean you don't like

use all;

which defines a UNIVERSAL::AUTOLOAD function to autoreuqire everything
whenever it has to? :-)

--tom

On Mon, 23 Oct 1995, Aaron Sherman wrote:

> I could really use the following for command-line hacks (like checking
> to see if some use of a library function is valid):
>
> env variable, "PERLMODS"
>
> Would be a space-separated list (or, whatever sep-char you
> wanted. Can't be ":"). Contains a list of modules that should be
> auto-used before parsing of the script.

Why not just use a simple shell (or perl) script wrapper (call it
perlm) that does this for you?

i.e. it would change
PERLMODS='POSIX Fcntl Socket'; export PERLMODS
perlm -e 'print "Hello, world\n";'
into
perl -e 'use POSIX; use Fcntl; use Socket;' -e 'print "Hello, world\n";'

Looks pretty easy to do. I can whip up perlm if need be.
That's my inclination, anyway, instead of adding more stuff to perl.

Andy Dougherty doughera@lafcol.lafayette.edu

> From: Andy Dougherty <doughera@lafcol.lafayette.edu>
>
> On Mon, 23 Oct 1995, Aaron Sherman wrote:
>
> > I could really use the following for command-line hacks (like checking
> > to see if some use of a library function is valid):
> >
> > env variable, "PERLMODS"
> >
> > Would be a space-separated list (or, whatever sep-char you
> > wanted. Can't be ":"). Contains a list of modules that should be
> > auto-used before parsing of the script.
>
> Why not just use a simple shell (or perl) script wrapper (call it
> perlm) that does this for you?
>
> i.e. it would change
> PERLMODS='POSIX Fcntl Socket'; export PERLMODS
> perlm -e 'print "Hello, world\n";'
> into
> perl -e 'use POSIX; use Fcntl; use Socket;' -e 'print "Hello, world\n";'
>
> Looks pretty easy to do. I can whip up perlm if need be.
> That's my inclination, anyway, instead of adding more stuff to perl.

Perl5.002 will hopefully have the -M and -m switches for
loading modules from the command line.

Perhaps there is scope for a

use perlrc;

kind'a module that would find one or more appropriate .perlrc files
(current dir, home dir) and execute it/them in the callers context.

With -M you could then say

perl -Mperlrc ...

(I'd probably never use perlrc myself but that's what I'd suggest
for those that like the idea.)

Tim.

Kenneth Albanowski writes:
> I see a rather useful addition to this idea, though: make -d work the
> same way. Currently, to use DProf you need the rather inelegant:
>
> PERL5DB="use Devel::DProf;" perl -d test.pl
>
> How about giving -d an argument, so you can say:
>
> perl -dDprof test.pl
>
> and it will automatically C<use Debug::DProf> before the program runs, in
> addition to turning on -d?
>

How would you parse
perl -de 0
? Though having
perl -d:Dprof test.pl
may be interesting.

Ilya

Andy Dougherty writes:
> Why not just use a simple shell (or perl) script wrapper (call it
> perlm) that does this for you?
>
> i.e. it would change
> PERLMODS='POSIX Fcntl Socket'; export PERLMODS
> perlm -e 'print "Hello, world\n";'
> into
> perl -e 'use POSIX; use Fcntl; use Socket;' -e 'print "Hello, world\n";'
>
> Looks pretty easy to do. I can whip up perlm if need be.
> That's my inclination, anyway, instead of adding more stuff to perl.
>

Having -d: recognized as in my previous message you can do it like
perl -d:m -e 'print "Hello, world\n"'

Ilya

> On Mon, 23 Oct 1995, Aaron Sherman wrote:

> > I could really use the following for command-line hacks (like checking
> > to see if some use of a library function is valid):
> >
> > env variable, "PERLMODS"
> >
> > Would be a space-separated list (or, whatever sep-char you
> > wanted. Can't be ":"). Contains a list of modules that should be
> > auto-used before parsing of the script.

> Why not just use a simple shell (or perl) script wrapper (call it
> perlm) that does this for you?

> i.e. it would change
> PERLMODS='POSIX Fcntl Socket'; export PERLMODS
> perlm -e 'print "Hello, world\n";'
> into
> perl -e 'use POSIX; use Fcntl; use Socket;' -e 'print "Hello, world\n";'

> Looks pretty easy to do. I can whip up perlm if need be.
> That's my inclination, anyway, instead of adding more stuff to perl.

yes, i don't think it really saves a lot in the long run, nor
does it seems superimportant when a perlm is so easy. cast my
vote for not changing perl for this.

--tom

On Tue, 24 Oct 1995, Ilya Zakharevich wrote:

> Kenneth Albanowski writes:
> > I see a rather useful addition to this idea, though: make -d work the
> > same way. Currently, to use DProf you need the rather inelegant:
> >
> > PERL5DB="use Devel::DProf;" perl -d test.pl
> >
> > How about giving -d an argument, so you can say:
> >
> > perl -dDprof test.pl
> >
> > and it will automatically C<use Debug::DProf> before the program runs, in
> > addition to turning on -d?
> >
>
> How would you parse
> perl -de 0
> ? Though having
> perl -d:Dprof test.pl
> may be interesting.

-d would become a switch that takes an argument, and thus isn't
"stackable". "-de" would be parsed as "the -d switch with an argument of
'e'".

> Ilya
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

On Tue, 24 Oct 1995, Tom Christiansen wrote:

> You mean you don't like
>
> use all;
>
> which defines a UNIVERSAL::AUTOLOAD function to autoreuqire everything
> whenever it has to? :-)

Neat. Especially if everybody is using "new X::Y" notation.

> --tom
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

I don't know. The more I think about it, the more I like the idea of a
dot-file. Assume that -r is unused (I don't know if it is or not).

perl -r ~/.perlrc somescript

would be the default usage. However, the -e flag would (given no
explicit -r flag) imply "-r ~/.perlrc".

You don't have to worry about setuid scripts, in this case, because the
author of the script is welcome to put

#!/perl -r /usr/local/bin/hurtme

Into the script, and taint will have a cow. This is what we expect if
the author was to expand this as:

eval `cat /usr/local/bin/hurtme`;

And, that's what tainting is for.

Now, that isn't to say that I dislike Kenneth's ideas about debugging,
and I would think you would want some -r to be implied by -d as well
(perhaps "-r ~/.perldbrc").

The point is that once you have a command-line parameter, you can make
the others do the right thing. Writing the code to do the file-eval is
the only serious work involved, I think. Is there something I'm
missing (like some "you can't eval before you fire up the parser,
which has to happen after command-line parsing" kind of race)?

-AJS

--
Aaron Sherman <ajs@ajs.com> This " " B4 f w+ c kv s+(--)v r p
I-Kinetics, Inc. for rent Pager: (508)545-0584
1 NE Executive Park Fax: (617)270-4979
Burlington, MA 01803-5005 Desk: (617)252-3489
ajs@ajs.com or ajs@openmarket.com WWW: http://ajs.com/~ajs/

You can create a wrapper for almost any feature (-p, -e, etc, etc,
etc). The question that you have to ask is, "will people benifit from
having a consistent interface to this feature". In the case of most of
the command-line arguments that exist, I would say yes. My suggestion
of a -r flag for evaling a dot-file is another question.

The benifit that I see is that people will be able to use a common
terminology to talk about initialization. I forsee the news posting:

Just put "use strict 9" in your .perlrc, and you'll never
have this problem again.

It gives people the option to have perl behave in ways that not
everyone would find acceptable, but which you would want to suggest
that the masses try. Saying,

Just install this script on your machine, and then put "use
less waist" in your .perlrc

is less likely to get J.R. User to do the right thing.

-AJS

--
Aaron Sherman <ajs@ajs.com> This " " B4 f w+ c kv s+(--)v r p
I-Kinetics, Inc. for rent Pager: (508)545-0584
1 NE Executive Park Fax: (617)270-4979
Burlington, MA 01803-5005 Desk: (617)252-3489
ajs@ajs.com or ajs@openmarket.com WWW: http://ajs.com/~ajs/

On Tue, 24 Oct 1995, Aaron Sherman wrote:

> The benifit that I see is that people will be able to use a common
> terminology to talk about initialization. I forsee the news posting:
>
> Just put "use strict 9" in your .perlrc, and you'll never
> have this problem again.

The thing is, this exact same scenario could be a major problem. Let's
say that somebody said "for better perl code, make sure to put 'use
strict;' in your .perlrc file". So now all the programs you write are
restricted to "strict", unless you have an explicit "no strict". But
doesn't this also mean that any _other_ programs you run, including
system ones, will be run under "strict", even if they are not expecting it?

This seems very dangerous.

> It gives people the option to have perl behave in ways that not
> everyone would find acceptable, but which you would want to suggest
> that the masses try. Saying,
>
> Just install this script on your machine, and then put "use
> less waist" in your .perlrc
>
> is less likely to get J.R. User to do the right thing.
>
> -AJS
>
> --
> Aaron Sherman <ajs@ajs.com> This " " B4 f w+ c kv s+(--)v r p
> I-Kinetics, Inc. for rent Pager: (508)545-0584
> 1 NE Executive Park Fax: (617)270-4979
> Burlington, MA 01803-5005 Desk: (617)252-3489
> ajs@ajs.com or ajs@openmarket.com WWW: http://ajs.com/~ajs/
>
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

Aaron Sherman <ajs@OpenMarket.com> writes:
> Aaron Sherman <ajs@OpenMarket.com> writes:
>>
>> [.It would be nice if perl would read a ~/.perlrc when running
>> one-liners from the command line.] Why? Because for command-line
>> work, listing 5 libraries takes up too much room, and when you want a
>> quick one-liner to verify something, having to edit a file is a pain
>> in the ass.
>
[...]
>
> In my second example (command-line parameters), you don't have a
> problem, because I suggested that -e would turn the parameter on, but
> otherwise it is off by default.

I tend to use perl -e in the middle of Makefiles, kermit scripts, legacy
shell scripts and other random places, so simply keying off of -e
wouldn't be safe. The only really safe way to tell if ~/.perlrc should
be processed would be to say it explicitly via a switch, perhaps -r
standing for rc or somesuch. If you had that sort of switch you might
turn it on in an alias which is only defined when you're typing commands
interactively, like

alias pe='perl -r'

If you have to go that far, however, I think you'd do just as well
simply to use something along the lines of

alias pe='perl -w -e"$(<~/.perlrc)"'

and not have to change perl at all.

--
Roderick Schertler
International Bonded Couriers/Miami
roderick@ibcinc.com

Saying

perl -e 'use RC; ...'

doesn't seem too terrible painful, where RC.pm resembles

require "$ENV{HOME}/.perlrc";

I picked the word "use" to be short on purpose.

Larry

Or even:

use ual;

to get the usual values. :-)

(ducking... :-)

Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@ora.com)
Web: <A HREF="http://www.teleport.com/~merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

Kenneth Albanowski writes:
> > How would you parse
> > perl -de 0
> > ? Though having
> > perl -d:Dprof test.pl
> > may be interesting.
>
> -d would become a switch that takes an argument, and thus isn't
> "stackable". "-de" would be parsed as "the -d switch with an argument of
> 'e'".
>

Yes, and hell with backward compatibility! ;-)

This is why I think one should go with -d:Dprof.

Ilya

Larry Wall writes:
>
> Saying
>
> perl -e 'use RC; ...'
>
> doesn't seem too terrible painful, where RC.pm resembles
>
> require "$ENV{HOME}/.perlrc";
>
> I picked the word "use" to be short on purpose.

With the -mfoo option for doing "use foo" from the command line,
it could be
perl -myrc -e 'something'

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

> From: Larry Wall <lwall@scalpel.netlabs.com>
>
> Saying
>
> perl -e 'use RC; ...'
>
> doesn't seem too terrible painful, where RC.pm resembles
>
> require "$ENV{HOME}/.perlrc";
>
> I picked the word "use" to be short on purpose.

And the next logical step

perl -MRC

would be shorter still.

Tim.

> From: Kenneth Albanowski <kjahds@kjahds.com>
>
> On Mon, 23 Oct 1995, Aaron Sherman wrote:
>
> There is a different way of looking at this, though. Back a bit, Tim (?)
> suggested a -m switch, so we could say "perl -man foo", and have the
> "Auto::an" package invoked, which in turn would do a lookup on "foo" in
> the manual. What if a similar facility was available, something like...
> Hmm... not to many switches left... OK, let's use -b, for begin:
>
> perl -bIO -e "$fh = new IO::Hanlde;#etc..."
> Or
> perl -bPOSIX,IO,Data::Dump -e "...";

Close but not quite (where did the Auto:: come from? I don't remember that.)

Larry has a patch from me in the bugs database which implements -M and -m
switches.

-MFoo => use Foo;
-mFoo => require Foo;

It is explicitly allowed for you to say

-M'Foo qw(bar baz)'

Multiple -M and -m switches can be used.

Tim.

>>>>> "Kenneth" == Kenneth Albanowski <kjahds@kjahds.com> writes:

Kenneth> On Tue, 24 Oct 1995, Aaron Sherman wrote:

[...]
Kenneth> make sure to put 'use strict;' in your .perlrc file". So now
Kenneth> all the programs you write are restricted to "strict",
[...]
Kenneth> This seems very dangerous.

No, you should never have programs turn on the command-line flag for
looking at the init file. Just -e.

-AJS

--
Aaron Sherman <ajs@ajs.com> This " " B4 f w+ c kv s+(--)v r p
I-Kinetics, Inc. for rent Pager: (508)545-0584
1 NE Executive Park Fax: (617)270-4979
Burlington, MA 01803-5005 Desk: (617)252-3489
ajs@ajs.com or ajs@openmarket.com WWW: http://ajs.com/~ajs/

On Wed, 25 Oct 1995, Malcolm Beattie wrote:

> Larry Wall writes:
> >
> > Saying
> >
> > perl -e 'use RC; ...'
> >
> > doesn't seem too terrible painful [ . . . ]
>
> With the -mfoo option for doing "use foo" from the command line,
> it could be
> perl -myrc -e 'something'

Which saves typing 7 characters. Well, 3, actually, since you'd probably
type:
perl -e 'use rc; something'

I guess I'm not convinced it's important to have yet a third way to say
BEGIN { require "rc.pm"; import rc; }

On the other hand, Tim apparently was and submitted a patch to implement
it. When people care enough about an issue to solve it themselves, I tend
to be sympathetic.

Andy Dougherty doughera@lafcol.lafayette.edu
--
To subscribe or unsubscribe, send your request (subscribe, unsubscribe)
in the BODY of a message to perl5-porters-request@africa.nicoh.com.

On Wed, 25 Oct 1995, Aaron Sherman wrote:

> >>>>> "Kenneth" == Kenneth Albanowski <kjahds@kjahds.com> writes:
>
> Kenneth> On Tue, 24 Oct 1995, Aaron Sherman wrote:
>
> [...]
> Kenneth> make sure to put 'use strict;' in your .perlrc file". So now
> Kenneth> all the programs you write are restricted to "strict",
> [...]
> Kenneth> This seems very dangerous.
>
> No, you should never have programs turn on the command-line flag for
> looking at the init file. Just -e.

But, as others have mentioned, what if MakeMaker uses a C<perl -e> buried
down inside it's Makefile? On the other hand, what if I feed a program
into 'perl' via STDIN, either by typing or pasting. Don't I still want my
RC features?

I'd say, just go with "use rc;", or a "perlr" script.

> -AJS
>
> --
> Aaron Sherman <ajs@ajs.com> This " " B4 f w+ c kv s+(--)v r p
> I-Kinetics, Inc. for rent Pager: (508)545-0584
> 1 NE Executive Park Fax: (617)270-4979
> Burlington, MA 01803-5005 Desk: (617)252-3489
> ajs@ajs.com or ajs@openmarket.com WWW: http://ajs.com/~ajs/
>
>

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)