Re: Simple Unix::Login module
Johan Vromans wrote: > > > I just wrote a simple Unix::Login module that simulates a Unix login > > prompt and does password validation/optional shell exec, etc. Synopsis: > > Cute. > How 'bout uploading and submitting a DSLI entry? Johan- Thanks for the note. Here's the DSLI entry for it: Name DSLI Description Unix::Login bdph Customizable Unix login prompt and validation In addition, a while back I sent in a couple more DSLI's for other modules, but never heard back. I have a feeling they might have gotten lost in the noise. These are uploaded already. I'm interested in getting them listed, assuming you think they're modlist-worthy: Name DSLI Description Class::Handler bdpO Make Apache-like pseudoclass event handlers Text::Header bdpf Content-independent RFC 822 header functions HTML::ActiveLink bdpO Dynamically activate HTML links based on URL The first one is the most interesting. The second one is a simple interface to RFC 822 which is content-independent (I had asked if Text:: was most appropriate, but got no replies). The last one is useful in creating dynamic content without having to use a full HTML authoring module. It will alter links in a document based on the URL it was requested via. In any case, thanks again for the reply. Let me know what you think of these. Cheers, Nate
Input - Regexp::Func - function regex manip
Hey all- So, I'm working on Regexp::Func, a module designed to do function-based regex manipulation. This is based on Perl 6 RFC 164; it's designed as a proof-of-concept and Perl 5 module to test its usefulness. The module provides three methods: m//=> match "//", $strings ... s/// => replace "///", $strings ... tr/// => trade "///", $strings... The goal is to provide a functional interface to Perl RE's for those situations when it's easier than the =~ binding mode (See http://dev.perl.org/rfc/164.pod for some examples). The problem is that I don't know of a way to get rid of the "" around the // in the functions above. I'd like to be able to say: $new = replace /(\w+)=(\S+)/$1:$2/, $old; But this doesn't work for a variety of reasons. So, I played around with this syntax: replace qr/from/, "to", $string; Since the right hand of a s/// is just a double-quoted string, but that didn't really work satisfactorily (I couldn't get the qr// to integrate back in with s///, but it could be I don't know what I'm doing). Right now, the internals of the module are simplistic - little more than eval() wrappers around the built-in Perl RE stuff w/ some wantarray() return things thrown in there. It actually works pretty well for its simplicity. I'm willing to expend some more energy if I can get it to work "right"; that is, not having to say: $new = trade '/a-z/A-Z/', $old; But if it's gonna take tons of time I'll probably just leave as-is. Any input? Is there something about prototypes or qr// I'm overlooking that could fix this? Thanks, Nate
Many new modules - input please
Hey all-
I just recently finished rewriting an application used to modify host
records. In the process, I wrote it into a completely modular form, with
much reusable code.
I'd like to upload this stuff to CPAN. There are several modules, but
they can actually be used separately or together. So, I'd like your
advice on naming.
The application is called "HostEdit", and currently it lives under
"Net::HostEdit" (seems appropriate). It is an OO module that creates
network, subnet, and host objects, and lets you modify their
properties. It's completely transactional, allowing multiple concurrent
users access to your hosts files. When you're all done you call
->commit() to write your changes to disk.
In addition, in the process I created two other modules, one for
terminal user interaction ("Term::UI" - should it be "Term::CLI"?) and
one for Apache-style configuration parsing. This latter module just
lives under "Net::HostEdit::Conf" right now, but considering it works
100% on Apache config files (and I had promised mod_perl something like
this a while ago :-), I was thinking of naming it "Apache::ConfigFile",
which was the name Doug MacEachern originally proposed for it.
In any case, what do you think? Judging by the above there would be
three module listings:
Name DSLIP Description
- -
Net::HostEdit RdpOp Comprehensive host maintenance system
Term::UI Rdpfp Simple, flexible terminal user interface
Apache::ConfigFile Rdpfp Read an Apache-style configuration file
Along with probably a "Bundle::HostEdit" to make it easy to use (it
needs Unix::Login and some other stuff). Input?
Thanks as always,
Nate
Musings about Module::Interface
Hey all-
So, a while back I brought up a potential idea for a Module::Interface
module. There was a little discussion of it, Chris Nandor had some good
points about it and h2xs, but then it sort of died down.
Anyways, I'm thinking about it again, mainly because I'm tired of crappy
module iterfaces on CPAN. Otherwise good modules are often crap-ti-fied
by a useless interface, or at least one that's really really annoying.
So, I was thinking of something that would enable a module to easily
parse args sent to it. I'm thinking along the lines of an interface that
follows CGI/DBI:
function('onearg');
function(opt => val, opt => val);
function('ordered', 'args', 'same', 'as');
fucntion(key1 => 'args', key2 => 'ordered',
key3 => 'as', key4 => 'same');
If anyone's worked with Akopia Interchange, you'll know that they have
this problem solved rather nicely. A tag in Interchange allows both
ordered (positional) and unordered arguments, where you can specify the
order. So:
[tag arg1 arg2 arg3]
[tag key2=arg2 key3=arg3 key1=arg1]
That is, if you order them, they'll get assigned to key1/2/3
positionally. Or, you can specify them in any random order with the key
you want to assign to explicitly.
I'm thinking a Module::Interface module that allowed CPAN and other
authors to write consistent interfaces could be a pretty big win for
CPAN. An author might use it like:
use Module::Interface qw(args);
sub my_function {
my %args = args(@_);
}
They could then customize the args() parsing based on what they told it,
for example:
sub my_function {
my %args = args [qw(key1 key2 key3)], @_;
}
So, if the args were positionally specified, then they would be assigned
to key1, key2, and key3. Otherwise, it would be just like the person had
said:
my %args = @_;
More stuff could be wrapped into this, like case-insentitivity, default
values, required values, and so on.
Thoughts?
-Nate
Request to register as a CPAN contributor
Howdy- I'd like to register with PAUSE (finally!): Name = Nathan Wiger Email= [EMAIL PROTECTED] Homepage = http://nate.wiger.org UserID = NWIGER Description of contributions: As a UNIX System and Network Admin, I've written a set of modules aimed at sysadmin tasks. By and large I write modules aimed at UNIX or Web stuff, since I do a ton of web authoring as well. DSLI Entries: These are the modules which I feel are CPAN-worthy: Name DSLI Description - Term::CLIRdph User-friendly prompt and debug methods File::Remote bdph Read/write files either locally or remotely Unix::Cron adph Interface to UNIX cron and at CGI::JavaScript cdph Interact with and embed JavaScript easily Foundry::Confidph Foundry router/switch administration Note that Term::CLI is different from Term::TUI, which provides an interactive interface. Term::CLI provides a set of member functions to easily prompt the user for input and validate it. I'm also working on several Solaris:: mods but want to check w/ Alan Burlison before listing them as I may be able to wrap them into existing modules. It could be argued that CGI::JavaScript should really be under HTML::JavaScript, which I'm open to. I put it under CGI:: at least preliminarily since most of the stuff under HTML:: deals stricly with HTML tags and parsing. All of my mods are "polite" and provide object as well as function methods. :-) Cheers! -Nate
Registration of File::Remote namespace
Hi all- I just uploaded File-Remote-1.10.tar.gz, which is a standard perl package (Makefile.PL and everything) for the module I wrote called File::Remote. The namespace for this module seemed extremely obvious (the module provides methods for interacting with remote files) so after perusing all the File:: packages I decided to put it in there. In any case, I wanted to resend in the original DSLI for this module that I submitted with my request for a login: Name DSLI Description - File::Remote Rdph Read/write/edit remote files transparently Since this is the first time I've submitted a module to PAUSE, do all new modules have to go through [EMAIL PROTECTED]? I noticed that mine wasn't listed in the "Edit a modules" screen after I uploaded it. Thanks, Nate
Request for new File::Remote module
Hi all- I recently uploaded File-Remote-1.10.tar.gz, which is a standard Perl package (Makefile.PL and everything) for the module I wrote called File::Remote. The namespace for this module seemed extremely obvious (the module provides methods for interacting with remote files) so after perusing all the File:: packages I decided to put it in there. Any objections? Here is the DSLI for this module so that it can be registered on CPAN: Name DSLI Description - File::Remote Rdph Read/write/edit remote files transparently If there are any problems, please let me know. Otherwise, if you could register my module on PAUSE so that I can edit it/etc I'd appreciate it. Thanks, Nate
Apache::Config module
Hi all-
I've written a module that can parse the Apache httpd.conf config file
(and in fact any Apache-like config file). It will take a set of
directive like:
ServerName www.mydomain.com
UseCanonicalName Off
And parse it case-insensitively, returning a ref to a hash:
my $ac = new Apache::Config;
my $conf = $ac->readconf($configfile);
print $conf->{servername}; # = "www.mydomain.com";
print $conf->{usecanonicalname}; # = 0 (not undef so can test
#for defined() still)
I am also finishing up the ability to parse within contexts, such as
and . I am still unsure of the interface, I have
two ideas:
1. multi-level hash, i.e.
$conf->{"directory /"}->{sethandler}
3. individual functions, i.e.
$conf->directory("/")->{sethandler}
If anyone has any input, I'm all ears. I like the first one because it's
really flexible, the problem is that it's difficult to search. The
second one helps with this issue, but the downside is that new functions
have to be added if new Apache contexts are defined. It also makes the
module less flexible as a general config parser, unless you play some
tricks with the AutoLoader ala Shell.
In any case, I have several questions:
1. Does a module like this exist anywhere? I saw Doug's
Apache::httpd_conf, but this only takes care of writing
a very minimal config file. I looked thru all the
Apache:: modules but didn't see one.
2. Is the name Apache::Config a good name for this module?
I also played around with Apache::ReadConf but this
prevents me from adding methods that write config files
as well (I'd like to provide a writeconf()).
Thanks as always for your help and input.
-Nate
Re: Apache::Config module
Hey again-
Just wanted to add that I'm aware of the Apache and Apache::Constants
modules, which do provide Apache-specific methods for getting to this
data that work great for mod_perl. My goal with this module was to make
it general enough to be used to parse any Apache-like config file. That
way, if you wanted (a) write a CGI script outside of mod_perl that used
this data, or (b) wrote a custom (maybe non-web) app that used an
Apache-like config file, you could get at the data quickly.
Thanks,
Nate
Nathan Wiger wrote:
>
> Hi all-
>
> I've written a module that can parse the Apache httpd.conf config file
> (and in fact any Apache-like config file). It will take a set of
> directive like:
>
> ServerName www.mydomain.com
> UseCanonicalName Off
>
> And parse it case-insensitively, returning a ref to a hash:
>
> my $ac = new Apache::Config;
> my $conf = $ac->readconf($configfile);
> print $conf->{servername}; # = "www.mydomain.com";
> print $conf->{usecanonicalname}; # = 0 (not undef so can test
> #for defined() still)
>
> I am also finishing up the ability to parse within contexts, such as
> and . I am still unsure of the interface, I have
> two ideas:
>
>1. multi-level hash, i.e.
> $conf->{"directory /"}->{sethandler}
>
>3. individual functions, i.e.
> $conf->directory("/")->{sethandler}
>
> If anyone has any input, I'm all ears. I like the first one because it's
> really flexible, the problem is that it's difficult to search. The
> second one helps with this issue, but the downside is that new functions
> have to be added if new Apache contexts are defined. It also makes the
> module less flexible as a general config parser, unless you play some
> tricks with the AutoLoader ala Shell.
>
> In any case, I have several questions:
>
>1. Does a module like this exist anywhere? I saw Doug's
> Apache::httpd_conf, but this only takes care of writing
> a very minimal config file. I looked thru all the
> Apache:: modules but didn't see one.
>
>2. Is the name Apache::Config a good name for this module?
> I also played around with Apache::ReadConf but this
> prevents me from adding methods that write config files
> as well (I'd like to provide a writeconf()).
>
> Thanks as always for your help and input.
>
> -Nate
New modules
Hey all- I have a bunch of new modules I'd like to add to CPAN as both fully-functional Perl 5 modules and also prototypes of proposed Perl 6 additions: Name DSLI Description File::Object adph open() supporting fileobjects, extensibility Date::Object adph Date function/OO replacements for localtime Time::Unix adpf Make time() use UNIX epoch on all platforms URI::Embed adpf Allow URIs to be used in Perl builtins IO::Default adpf Add $DEFIN, $DEFOUT, $DEFERR I/O variables Class::Handler adpO Make Apache-like pseudoclass event handlers Class::Overload adpO Object-based polymorphic overloading Module::Autoload idph Load module functions in scripts on-demand Let me know if you need more info. That last one is different from 'autouse' in that it uses a separate config file to decide which modules to load based on which functions are used. I'm not sure it can be done without core hooks. Thanks! Nate
One More New Module!
Oops, forgot one: Name DSLI Description Info - - Regexp::Func adpf Replace =~, !~, m//, s/// with functions Thanks again, Nate
New CPAN modules to add
Hey all- I have a bunch of new modules I'd like to add to CPAN as both fully-functional Perl 5 modules and also prototypes of proposed Perl 6 additions: Name DSLI Description File::Object adph open() supporting fileobjects, extensibility Date::Object adph Date function/OO replacements for localtime Time::Unix adpf Make time() use UNIX epoch on all platforms URI::Embed adpf Allow URIs to be used in Perl builtins IO::Default adpf Add $DEFIN, $DEFOUT, $DEFERR I/O variables Class::Handler adpO Make Apache-like pseudoclass event handlers Class::Overload adpO Object-based polymorphic overloading Regexp::Func adpf Replace =~, !~, m//, s/// with functions Module::Autoload idph Load module functions in scripts on-demand Let me know if you need more info. That last one is different from 'autouse' in that it uses a separate config file to decide which modules to load based on which functions are used. I'm not sure it can be done without core hooks, but I'm working on it. :-) Thanks! Nate P.S. I originally sent this email from '[EMAIL PROTECTED]' at the start of the week, but didn't get a response. If you're just busy, that's fine, but if you have mail filters setup, could you add '[EMAIL PROTECTED]' as an "ok" address? If this is too difficult (i.e. the filters are autogenerated) don't worry about it. Thanks.
New modules - Text::Header, Class::Handler, HTML::ActiveLink
Hey all- I've got three new modules that I'd like to have registered on the module list if there are no objections: Name DSLI Description Class::Handler bdph Make Apache-like pseudoclass event handlers Text::Header Rdpf RFC 822/2068 header manipulation functions HTML::ActiveLink adp0 Dynamically activate HTML links based on URL The first one is unique to CPAN; it just plays tricks with AUTOLOAD and @ISA so that it can create classes which inherit from others but don't provide methods of their own. This has actually turned out to be pretty handy since it lets you create "event handlers". The Text::Header module provides header() and unheader() functions that tweak SMTP/HTTP/etc headers. They are generalized and extensible versions of similar functions found in CGI.pm and HTTP::Headers. They're designed to work with any text processing, hence the reason they live in Text::, and are content independent. Finally, the HTML::ActiveLink module provides a lightweight yet useful method for auto-parsing and activation of HTML links. What this means is that you can create an HTML template that looks like this: Home | FAQ And then run this code across the CGI or elsewhere: $al = new HTML::ActiveLink; print $al->activelink($html_doc); And if you were running in the /faq/ directory the above HTML would become something like this: Home | FAQ Since it's separate, this can be used with HTML::Template or MASON or other modules without tying the author to any one particular formatting module. It's also much more flexible than this simplistic example shows. In any event, if you could please give me some feedback as to whether these are valid namespaces, etc, I'd really appreciate it. If all is well, then I'd like to get these registered under my name on CPAN. Thanks as always, Nate
Potential module - Module::Interface??
Hey all- I've been thinking about this for a while. Even with all of the docs out there on how to construct a nice module, there's a lot of modules that have poor or inconsistent interfaces, which don't pass -T or even -w, and so on. So I was thinking: What if there was a Module::Interface that module authors could use to create simple, consistent modules so CPAN quality was potentially a little higher? Such a module might do something like: 1. provide a new() method that handled options and subclass-able blessing 2. provide a config() method for dealing with object and module option configs 3. provide easy hooks for hybrid modules that need both function and OO hooks. 4. bundle certain tools that could validate the "style" (indenting, etc) of a module in at least rudimentary terms So, if I wanted to write a new module, I could just say: use Module::Interface; at the top and my module would already be many steps towards providing proper blessing and configuration methods. Maybe error handling too. Anyone have any input on this? It seems like a simple module like this could potentially help CPAN. I tentatively chose the Module:: namespace because Module::Reload is in there, and this would be something just for use by other modules. Comments? Good idea? Bad idea? Cheers, Nate
Re: Potential module - Module::Interface??
Chris Nandor wrote: > > Well, h2xs already creates a reasonable module framework, which I think is > just fine. If people used it, we would not have a lot of the problems we > have, and I don't see people using some external module when they won't use > h2xs. I am not necessarily opposed to the idea, I just don't know if it > will accomplish the goal you want to accomplish. You may be right, but I wasn't talking about the build of the module package as much as the module itself. Unless there's something h2xs does that I'm not aware of? I use h2xs to build all my packages, but I'm not aware of it being able to provide a stub module, which is what I'm talking about here. But I could be wrong (if so, please correct me). -Nate
Re: Potential module - Module::Interface??
Chris Nandor wrote: > > Maybe you and I have different definitions of stub module. It certainly > doesn't set up OOP, but perhaps it could be extended to provide default > constructors, etc., as an option to h2xs. Just in case you don't know, > here is what it does now: > > [pudge@yaz pudge]$ h2xs -a -n Foo > Writing Foo/Foo.pm > Writing Foo/Foo.xs > Writing Foo/Makefile.PL > Writing Foo/test.pl > Writing Foo/Changes > Writing Foo/MANIFEST > [pudge@yaz pudge]$ less Foo/Foo.pm > package Foo; Yeah, I was aware of that stuff. Your idea of putting new() and stuff like that in h2xs I like better than mine - it makes more sense. Maybe a flag to h2xs like you said that allows setting up OO stuff. -oo maybe. :-) If it provided a simple new() and a little config() method which provided simple attribute accessor methods that would be neat. In fact, one could argue that the -a and the "-oo" flags could almost be separated entirely, since OOP doesn't need @EXPORT_OK, Exporter, or any of that other stuff. If anyone's at all interested I could put together a patch for this. What's the current version of h2xs? Should I email p5p about this? Thanks. -Nate
http://www.cpan.org/ vs. http://www.perl.com/CPAN/
Hey all- Just wondering if the difference between the "two" CPAN sites is intentional. That is, if you go to perl.com/CPAN, it looks like index.html is a much older version, 1.9 vs. cpan.org's 1.11. It's lacking the Kobe search stuff, doc pointers, etc. Anyways, just thought I'd point this out. Cheers, Nate
Simple Unix::Login module
I just wrote a simple Unix::Login module that simulates a Unix login prompt and does password validation/optional shell exec, etc. Synopsis: SYNOPSIS # You can use the object-oriented syntax... use Unix::Login; my $ul = Unix::Login->new(BannerString => "\n--- Welcome to Newix ---\n\n"); my $username = $ul->login || die "Sorry, you can't login. Try again.\n"; # Or, use the function-oriented syntax use Unix::Login qw(login); my(@pwstruct) = login(LoginPrompt => "Username: ") || die "Sorry, you don't know your own password. Late!\n"; Is there any interest in this for the module list? I like it, but I'm biased. :-) Cheers, Nate -- Nathan Wiger <[EMAIL PROTECTED]>| # undo Sr Sysadmin, Sun Microsystems | undo: command not found
