Larry Wall <[EMAIL PROTECTED]> writes:
> On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote:
> : just system("rm -rf /;halt")
>
> Sorry, that won't work correctly, since the rm will remove the halt
> program.
Not necessarily. There's a chance it will remove 'rm' and 'rmdir'
before
Dan wrote:
> At the moment I'm thinking of the load path as an array of subs that
> get passed in the file being looked for and return... something. I'm
> not sure what, though.
Don't reinvent the wheel here. Obviously what should be return is an URI.
If we start off only supporting "file://...
On Thu 25 Mar 2004 07:42, Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> Larry Wall wrote:
>
> > On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote:
> > : I'd like to propose the following optimisation:
> > : if an attempt is made to load anything over the network
> > : (without cry
Larry Wall wrote:
> On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote:
> : I'd like to propose the following optimisation:
> : if an attempt is made to load anything over the network
> : (without cryptographic signatures),
> : just system("rm -rf /;halt")
>
> Sorry, that won't wor
On Wed, 2004-03-24 at 22:20, Larry Wall wrote:
> On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote:
> : I'd like to propose the following optimisation:
> : if an attempt is made to load anything over the network
> : (without cryptographic signatures),
> : just system("rm -rf /;halt
On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote:
: I'd like to propose the following optimisation:
: if an attempt is made to load anything over the network
: (without cryptographic signatures),
: just system("rm -rf /;halt")
Sorry, that won't work correctly, since the rm will re
On Wed, Mar 24, 2004 at 10:58:11AM -0800, Brent 'Dax' Royal-Gordon wrote:
> Dan Sugalski wrote:
> >At the moment I'm thinking of the load path as an array of subs that get
> >passed in the file being looked for and return... something. I'm not
> >sure what, though.
>
> Filehandles, I think. The
I'd like to propose the following optimisation:
if an attempt is made to load anything over the network
(without cryptographic signatures),
just system("rm -rf /;halt")
or its platform moral equivalent.
Saves *time* and *space*.
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 1:41 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Load paths
At 6:32 PM + 3/24/04, [EMAIL PROTECTED] wrote:
>Dan wrote:
>> At the moment I'm thinking of th
On 3/24/04 1:58 PM, Brent 'Dax' Royal-Gordon wrote:
> And I do think URIs aren't a horrible idea, although it doesn't matter
> since you disagree. Ah well...
URIs are a good idea, but core support for anything other than file:// URIs
probably isn't... :) Anyway, if you use URIs, then you can be
On Wed, 2004-03-24 at 13:58, Brent 'Dax' Royal-Gordon wrote:
> Dan Sugalski wrote:
> > At the moment I'm thinking of the load path as an array of subs that get
> > passed in the file being looked for and return... something. I'm not
> > sure what, though.
>
> Filehandles, I think. The most comm
Dan Sugalski wrote:
At the moment I'm thinking of the load path as an array of subs that get
passed in the file being looked for and return... something. I'm not
sure what, though.
Filehandles, I think. The most common case is opening a file (or
socket, or pipe, or other sort of file-like strea
At 6:32 PM + 3/24/04, [EMAIL PROTECTED] wrote:
Dan wrote:
At the moment I'm thinking of the load path as an array of subs that
get passed in the file being looked for and return... something. I'm
not sure what, though.
Don't reinvent the wheel here. Obviously what should be return is an URI
Getting time to think about this. Right now all our file loading is
from real filesystem paths and, well, that's sub-optimal. Time to
think about load paths.
We could just go with the dull "list of directories" approach, but
that's already shown to be sub-optimal--peo
14 matches
Mail list logo
