Front page | perl.perl5.porters |
Postings from April 2003
Perl script execution
Thread Previous
|
Thread Next
From:
Poornima
Date:
April 7, 2003 04:00
Subject:
Perl script execution
Message ID:
002901c2fcf4$a8cca980$0700a8c0@awww.angleritech.com
I executed a program in the Internet browser.
I closed the browser & the program stops executing.
Can anyone tell me how to execute a program recursively in the backend even
after closing the Internet browser.
Kindly mail me at the earliest.
Thanks in advance.
Poornima.
----- Original Message -----
From: Stas Bekman <stas@stason.org>
To: <poornima@angleritech.com>
Cc: Andreas J. Koenig <andreas.koenig@anima.de>; <module-authors@perl.org>;
<perl5-porters@perl.org>; <autrijus@cpan.org>
Sent: Friday, March 28, 2003 8:06 AM
Subject: Re: rfc: a generic solution for dual-life CPAN packages
> The more I think about it the more I like my latest idea. I'm going to
> expand on it in this post as I think it may do more things than just
> solving the bundling problem.
>
> What I'm proposing is to have a mechanism similar to /robots.txt in
> the HTTP protocol, where '/' is the root of the web server namespace
> So now we have "the CPAN indexer protocol" and we introduce /INDEX,
> where / is the top-level directory of a given package.
>
> /INDEX provides a way for a package to tell the indexer what it wants
> to be exposed and/or what not. We can work out a simple syntax, like:
>
> +lib/ # expose all packages under lib/
> -lib/private.pm # but exclude lib/private.pm
> +lib2/Foo.pm # expose lib2/Foo.pm
>
> Of course the simplest version is to just specify what modules are to
> be excluded (implying that the rest are to be included):
>
> -inc/ # exclude all packages under inc
> -lib/private.pm # exclude lib/private.pm
>
> Of course it may support globbing as well. e.g. -lib/*/*_private.pm
>
> In the future we may introduce new syntax to have more ways for the
> package to talk to the indexer(s). e.g. we may have new indexers,
> which we may want to tell them different things (just like with HTTP
> robots).
>
> Why this is beneficial to the /inc solution:
>
> - it's flexible and not hardcoded, casted in stone, solution
>
> - the developer has a full control over what it wants to be exposed
> and what not.
>
> - the developer deciding to split one of the modules into a separate
> package, while keeping the include, only needs to add these modules
> to /INDEX. He doesn't have to change the filesystem layout, which is
> also a problem if cvs is used (losing history).
>
> - the developer may decide to fold some dual-life package, back into
> its original source. Again only one file needs to be modified, no fs
> change is required.
>
> - the developer may have a master module in a bigger package, and also
> distribute it separately on CPAN for user's convenience. Moving that
> master module into a special directory is not convenient at all, and
> while possible to do during 'make dist' it may cause problems during
> the build time, if some code was expecting to find the module in the
> original place.
>
> - in certain cases /inc solution simply doesn't work. My package
> DocSet includes several examples, which can't live in /inc or
> /t. Unfortunately the indexer picks them up. e.g. it picks the
> example module DB_File::Lock2:
>
> cpan> i /DB_File::Lock/
> Module DB_File::Lock (D/DH/DHARRIS/DB_File-Lock-0.05.tar.gz)
> Module DB_File::Lock2 (S/ST/STAS/DocSet-0.15.tar.gz)
> 2 items found
>
> If tomorrow someone else releases a
> real module DB_File::Lock2, user wanting to install it may install
> DocSet instead of that real package. Notice that in this case, the
> collision is not under control of the other author who has released
> the same package. I could have avoided it in first place if I could
> tell indexer not to index the example modules. Notice that the
> DocSet package has this module as:
> examples/site/src/docs/1.0/guide/code/DB_File-Lock2.pm
>
> - indexer doesn't have to introduce a special solution for the
> perl-core, as it can list all the dual-life packages in that
> file. Then the perl-core is no longer restricted to put the
> dual-life package into a special dir.
>
> - currently used hadrcoded solution using /inc is still supported, by
> simply adding /inc to /INDEX (-/inc)
>
> - CPAN::MakeMaker only needs to include the bundled files in /INDEX
> and may put them under any dir it feels like.
>
> -----
>
> I don't really care how this special file is to be called, or what the
> inclusion/exclusion syntax is. the point is to have the functionality
> in place.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
Thread Previous
|
Thread Next