[30206] in Perl-Users-Digest
Perl-Users Digest, Issue: 1449 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Apr 15 16:25:50 2008
Date: Tue, 15 Apr 2008 13:25:40 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 15 Apr 2008 Volume: 11 Number: 1449
Today's topics:
Textview not scrolling to show full text in IRC client <deadpickle@gmail.com>
Time::HiRes < 1.91 and glibc 2.4 incompatibility <Mark.Seger@hp.com>
Re: Time::HiRes < 1.91 and glibc 2.4 incompatibility <smallpond@juno.com>
Re: Time::HiRes < 1.91 and glibc 2.4 incompatibility <Mark.Seger@hp.com>
Re: Time::HiRes < 1.91 and glibc 2.4 incompatibility <smallpond@juno.com>
Re: Time::HiRes < 1.91 and glibc 2.4 incompatibility <Mark.Seger@hp.com>
Re: Time::HiRes < 1.91 and glibc 2.4 incompatibility <Mark.Seger@hp.com>
Re: Trouble with @ARGV <ff0000.it@gmail.com>
Re: Trouble with @ARGV <rkb@i.frys.com>
Re: Trouble with @ARGV <jimsgibson@gmail.com>
Re: Trouble with @ARGV <ff0000.it@gmail.com>
Uninitialized values in hash <mikaelpetterson@hotmail.com>
Re: Uninitialized values in hash <devnull4711@web.de>
Re: Uninitialized values in hash <mikaelpetterson@hotmail.com>
Re: Uninitialized values in hash <gueltig-bis-30-03-2008@nurfuerspam.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 14 Apr 2008 13:23:10 -0700 (PDT)
From: deadpickle <deadpickle@gmail.com>
Subject: Textview not scrolling to show full text in IRC client
Message-Id: <cc9b3e44-b9c1-4569-9817-9fe708961b6a@a22g2000hsc.googlegroups.com>
I have this IRC client that wont scroll far enough down to show the
full text. Its rather hard to explain but I'll give it a try:
when you get down to the bottom on the textview and you go to enter a
message such as:
John(10:00:00) I have to go to the story today and get some fruit.
And this message is the last one to be entered before the bottom of
the window therefore causing it to have to scroll down, the program
only shows the first line:
John(10:00:00) I have to go to the story
Forcing the user to scroll down to view the rest:
today and get some fruit.
You can see that this would be a problem when users are chatting,
having to always take your attention off of the session just to scroll
down and view the whole message. Currently the program uses the code
$chat_textview->scroll_to_mark wher mark is the end iter of the
buffer. I cant figure how to get this to work and show the whole text
without the user having to manually scroll down. I figured that this
would do it but it wont work. Here is the code, its functional so you
can try it and see what I mean.
#!/usr/local/bin/perl -w
use strict;
use Gtk2 '-init';
use Glib qw/TRUE FALSE/;
use Net::IRC;
use threads;
use threads::shared;
my $irc = new Net::IRC;
my $chat_state = 'Connect';
my $chat_entry;
my $chat_send_sig;
my $chat_textview;
my $chat_button;
my $sys_msg;
my $tag;
my $job = 1;
my $die:shared = 0;
my $chat_start:shared = 0;
my $channel:shared = "#GRRUVI";
my $irc_server:shared = "irc.servercentral.net";
my $nick:shared = "VCBase";
my $msg:shared;
my $post:shared = 0;
my $name:shared = 0;
my $list:shared;
#################################################
#Threads
my $thread_chat = threads->new(\&chat);
#################################################
#################################################
#Timeout
my $timer_post = Glib::Timeout->add(100, \&post);
#################################################
#-------------------Main Loop-------------------
&chat_build;
Gtk2->main;
####################CHAT BLOCK####################
#-------------------chat Build-------------------
sub chat_build {
my $chat_window = Gtk2::Window->new('toplevel');
$chat_window->set_title('Chat Client');
$chat_window->set_position('center');
$chat_window->set_default_size( 300, 300 );
$chat_window->signal_connect(delete_event=> sub{
$die = 1;
$thread_chat->join;
Gtk2->main_quit;
});
$chat_entry = Gtk2::Entry->new;
my $chat_vbox = Gtk2::VBox->new;
my $chat_scroll = Gtk2::ScrolledWindow->new(undef, undef);
$chat_scroll->set_policy('never', 'always');
$chat_scroll->set_shadow_type( 'etched-out');
$chat_textview = Gtk2::TextView->new;
my $chat_buffer = $chat_textview->get_buffer;
$chat_buffer->create_mark( 'end', $chat_buffer->get_end_iter,
FALSE );
$chat_buffer->signal_connect(insert_text => sub {
$chat_textview->scroll_to_mark( $chat_buffer->get_mark('end'),
0.0, TRUE, 0.0, 1.0 );
});
$chat_button = Gtk2::Button->new;
$chat_button->set_label($chat_state);
# allows for sending each line with an enter keypress
$chat_send_sig = $chat_entry->signal_connect ('key-press-event' =>
sub {
my ($widget,$event)= @_;
if( $event->keyval() == 65293){ # a return key press
$msg = $chat_entry->get_text;
$chat_entry->set_text('');
$chat_entry->set_position(0);
$chat_start = 2;
$name = $nick;
$post = 6;
#print "$chat_start\n";
}
});
$chat_entry->signal_handler_block($chat_send_sig); #not connected
yet
$chat_entry->set_editable(0);
$chat_textview->set_editable(0);
$chat_textview->set_cursor_visible(0);
$chat_textview->set_wrap_mode('char');
$chat_scroll->add($chat_textview);
$chat_vbox->add($chat_scroll);
$chat_vbox->pack_start( $chat_entry, FALSE, FALSE, 0 );
$chat_vbox->pack_start( $chat_button, FALSE, FALSE, 0 );
$chat_window->add($chat_vbox);
$chat_window->show_all;
$chat_button->signal_connect("clicked" => sub {
if ($chat_state eq 'Connect') {
$chat_button->set_label('Disconnect');
$chat_state='Disconnect';
$chat_start = 1;
#$chat_entry->set_editable(1);
#$chat_entry->grab_focus;
#$chat_entry->signal_handler_unblock ($chat_send_sig);
$post = 1;
}
else {
$chat_button->set_label('Connect');
$chat_state='Connect';
$chat_start = 0;
#$chat_entry->set_editable(0);
#$chat_entry->grab_focus;
#$chat_entry->signal_handler_block ($chat_send_sig);
$post = 5;
}
});
return 1;
}
#-------------------Post to Textview-------------------
sub post {
#my ($name, $msg) = @_;
my @time = gmtime;
my $hour = $time[2];
my $min = $time[1];
my $sec = $time[0];
$hour = "0$time[2]" if $time[2] < 10;
$min = "0$time[1]" if $time[1] < 10;
$sec = "0$time[0]" if $time[0] < 10;
my $post_time = "($hour:$min:$sec)";
my $chat_buffer = $chat_textview->get_buffer;
#connecting
if ($post == 1){
$chat_buffer->insert( $chat_buffer->get_end_iter, "Connecting
to $irc_server..\n" );
$post = 0;
print CHAT "Connecting to $irc_server..\n" if $job == 3;
}
#Connected
if ($post == 2){
$chat_buffer->insert( $chat_buffer->get_end_iter, "Connected
to $irc_server\n" );
$chat_entry->set_editable(1);
$chat_entry->grab_focus;
$chat_entry->signal_handler_unblock ($chat_send_sig);
$post = 0;
print CHAT "Connected to $irc_server\n" if $job == 3;
}
#Joined
if ($post == 3){
if ($name ne $nick){
$chat_buffer->insert_with_tags( $chat_buffer-
>get_end_iter, "$name Joined $channel$post_time\n", $chat_buffer-
>create_tag($tag, foreground=>'red'));
}
else{
$chat_buffer->insert( $chat_buffer->get_end_iter, "$name
Joined $channel$post_time\n");
}
$post = 0;
print CHAT "$name Joined $channel$post_time\n" if $job == 3;
}
#Users
if ($post == 4){
#print "$list\n";
$chat_buffer->insert( $chat_buffer->get_end_iter, "Users on
$channel: $list\n" );
$post = 0;
print CHAT "Users on $channel: $list\n" if $job == 3;
}
#disconnect
if ($post == 5){
$chat_buffer->insert( $chat_buffer->get_end_iter,
"Disconnecting$post_time\n" );
$chat_entry->set_editable(0);
$chat_entry->grab_focus;
$chat_entry->signal_handler_block ($chat_send_sig);
$post = 0;
print CHAT "Disconnecting$post_time\n" if $job == 3;
}
#Posts
if ($post == 6){
if ($name ne $nick){
$chat_buffer->insert_with_tags( $chat_buffer-
>get_end_iter, "$name$post_time: $msg", $chat_buffer->create_tag($tag,
foreground=>'red'));
}
else{
$chat_buffer->insert( $chat_buffer->get_end_iter, "$name
$post_time: $msg\n");
}
print CHAT "$name$post_time: $msg\n" if $job == 3;
$post = 0;
}
#Disconnected
if ($post == 7){
$chat_buffer->insert( $chat_buffer->get_end_iter,
"Disconnected->Reconnecting$post_time\n");
print CHAT "Disconnected->Reconnecting$post_time\n" if $job ==
3;
$post = 0;
}
#Nick taken
if ($post == 8){
$chat_buffer->insert( $chat_buffer->get_end_iter, "Nick is
Taken->Please Change\n");
$chat_entry->set_editable(0);
$chat_entry->grab_focus;
$chat_entry->signal_handler_block ($chat_send_sig);
$chat_start = 0;
$chat_state = 'Connect';
$chat_button->set_label($chat_state);
$chat_buffer->insert( $chat_buffer->get_end_iter, "Nick is
Taken->Please Change\n" );
print CHAT "Connecting to $irc_server..\n" if $job == 3;
$post = 0;
}
#Quit
if ($post == 9){
$chat_buffer->insert_with_tags( $chat_buffer->get_end_iter,
"$name has QUIT$post_time\n", $chat_buffer->create_tag($tag,
foreground=>'red'));
print CHAT "$name has QUIT$post_time\n" if $job == 3;
$post = 0;
}
return 1;
}
##################################################
####################Threads####################
sub chat{
while (1){
my $conn;
goto END if $die == 1;
if ($chat_start == 1){
print "starting...\n";
$conn = $irc->newconn(Server => $irc_server,
Port => 6667,
Nick => $nick,
Ircname => "CoCoNUE Member $nick")
or die "Can't connect to IRC server\n";
#Install Handlers
$conn->add_handler('cping',
\&on_ping); #
$conn->add_handler('crping',
\&on_ping_reply); #
$conn->add_handler('join',
\&on_join); #3
$conn->add_handler('quit',
\&on_quit); #9
$conn->add_handler('public',
\&on_public); #6
$conn->add_global_handler([ 251,252,253,254,302,255 ],
\&on_init);
$conn->add_global_handler('disconnect',
\&on_disconnect); #7
$conn->add_global_handler(376,
\&on_connect); #2
$conn->add_global_handler(433,
\&on_nick_taken); #8
$conn->add_global_handler(353,
\&on_names); #4
for (;;){
$irc->do_one_loop;
#print "Looped: Reading\n";
if ($chat_start == 2){
#print "Looped: Sending\n";
$conn->privmsg("$channel", "$msg");
$chat_start = 1 if $chat_start != 0;
}
goto END if $die == 1;
last if $chat_start == 0;
}
$irc->removeconn($conn);
}
}
END:
}
#-------------------Handlers-------------------
# What to do when the bot successfully connects.
sub on_connect {
my $self = shift;
$post = 2;
sleep 1;
print "Joining $channel...\n";
$self->join("$channel");
}
# Handles some messages you get when you connect:::For testing
sub on_init {
my ($self, $event) = @_;
my (@args) = ($event->args);
shift (@args);
print "*** @args\n";
}
# What to do when someone leaves a channel the bot is on.
sub on_quit {
my ($self, $event) = @_;
#my ($channel) = ($event->to)[0];
$name = $event->nick;
$post = 9;
printf "*** %s has left channel %s\n", $event->nick, $channel;
}
# What to do when someone joins a channel the bot is on.
sub on_join {
my ($self, $event) = @_;
#my ($channel) = ($event->to)[0];
$name = $event->nick;
$post = 3;
sleep 1;
printf "*** %s (%s) has joined channel %s\n",
$event->nick, $event->userhost, $channel;
if ($event->userhost =~ /^corbeau\@.*execpc\.com/) { # Auto-ops
anyone who
$self->mode("#IRC.pm", "+o", $event->nick); # matches hostmask.
}
}
# Prints the names of people in a channel when we enter.
sub on_names {
my ($self, $event) = @_;
my (@list) = ($event->args); # eat yer heart out, mjd!
# splice() only works on real arrays. Sigh.
($channel, @list) = splice @list, 2;
$list = join(" ", @list);
print "$list\n";
$post = 4;
print "Users on $channel: @list\n";
}
# Yells about incoming CTCP PINGs.
sub on_ping {
my ($self, $event) = @_;
my $name = $event->nick;
$self->ctcp_reply($name, join (' ', ($event->args)));
print "*** CTCP PING request from $name received\n";
}
# Gives lag results for outgoing PINGs.
sub on_ping_reply {
my ($self, $event) = @_;
my ($args) = ($event->args)[1];
my ($name) = $event->nick;
$args = time - $args;
print "*** CTCP PING reply from $name: $args sec.\n";
}
# Change our nick if someone stole it.
sub on_nick_taken {
my ($self) = shift;
#$chat_start = 0;
#$chat_state = 'Connect';
$post = 8;
#$self->nick(substr($self->nick, -1) . substr($self->nick, 0, 8));
}
# Reconnect to the server when we die.
sub on_disconnect {
my ($self, $event) = @_;
$post = 7;
print "Disconnected from ", $event->from(), " (",
($event->args())[0], "). Attempting to reconnect...\n";
$self->connect();
}
# What to do when we receive channel text.
sub on_public {
my ($self, $event) = @_;
my @to = $event->to;
my ($them, $me) = ($event->nick, $self->nick);
($msg) = ($event->args);
$name = $event->nick;
#$msg = $arg;
$post = 6;
# Note that $event->to() returns a list (or arrayref, in scalar
# context) of the message's recipients, since there can easily be
# more than one.
print "<$them> $msg\n";
}
------------------------------
Date: Sat, 12 Apr 2008 08:46:03 -0400
From: Mark Seger <Mark.Seger@hp.com>
Subject: Time::HiRes < 1.91 and glibc 2.4 incompatibility
Message-Id: <ftqaud$f50$1@usenet01.boi.hp.com>
A long time ago I found a very peculiar timing bug in my open source
performance monitoring tool 'collectl' - I discovered that when glibc
went from version 2.3 to 2.4 it changed the time resolution from
microseconds to nanoseconds, going from 32 bits to 64 bits. It also
tuned out at the time the only one to make the move to that newer glibc
was SuSE. Anyhow, that change broke Time::HiRes for any timing greater
than 4.2 seconds!
I contacted the author of HiRes and he fixed it in the 1.91 release and
things have been fine since. Then yesterday I got an email from a user
who reported unusual timing problems with inconsistent monitoring
intervals which stumped me because collectl does very precise timing,
down to usecs. After a lot of digging around I realized this was the
same problem. Furthermore I also noticed even RHEL5.1 is only using
HiRes 1.86, though I also see they're running glibc 2.5. My first fear
was this is gonna break everywhere but now I'm also thinking it may have
been glibc 2.4 specific.
What I would like to do is check the version of HiRes someone is using
along with which version of glibc they've got and warn them if there's a
problem. I do know I can get the version of HiRes via
Time::HiRes->VERSION, but don't know if there's any way to get a library
version. I know on redhat I can see a version in the library name, but
I don't know if that will always be the case on all distros. I also
don't want to put too much pain into this because things do see to work
ok with 2.5 and so there may be a very small number of systems effected.
However I'm always looking to reduce support questions from users and
as the popularity of collectl grows I want to head off as much of this
sort of thing in the future if I can.
As a bonus question does anyone have any additional experiences with
versions of HiRes and glibc incompatibilities? and if so am I'm right
that things are ok with 2.5?
-mark
------------------------------
Date: Sun, 13 Apr 2008 05:45:58 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: Time::HiRes < 1.91 and glibc 2.4 incompatibility
Message-Id: <cce9662a-58bb-4752-ba21-32ed53ae0e92@a70g2000hsh.googlegroups.com>
On Apr 12, 8:46 am, Mark Seger <Mark.Se...@hp.com> wrote:
> A long time ago I found a very peculiar timing bug in my open source
> performance monitoring tool 'collectl' - I discovered that when glibc
> went from version 2.3 to 2.4 it changed the time resolution from
> microseconds to nanoseconds, going from 32 bits to 64 bits. It also
> tuned out at the time the only one to make the move to that newer glibc
> was SuSE. Anyhow, that change broke Time::HiRes for any timing greater
> than 4.2 seconds!
What call into glibc changed?
------------------------------
Date: Sun, 13 Apr 2008 10:18:01 -0400
From: Mark Seger <Mark.Seger@hp.com>
To: smallpond <smallpond@juno.com>
Subject: Re: Time::HiRes < 1.91 and glibc 2.4 incompatibility
Message-Id: <48021619.2090509@hp.com>
smallpond wrote:
> On Apr 12, 8:46 am, Mark Seger <Mark.Se...@hp.com> wrote:
>> A long time ago I found a very peculiar timing bug in my open source
>> performance monitoring tool 'collectl' - I discovered that when glibc
>> went from version 2.3 to 2.4 it changed the time resolution from
>> microseconds to nanoseconds, going from 32 bits to 64 bits. It also
>> tuned out at the time the only one to make the move to that newer glibc
>> was SuSE. Anyhow, that change broke Time::HiRes for any timing greater
>> than 4.2 seconds!
>
>
> What call into glibc changed?
I honestly don't know the details. What I do know is if you call ualarm
with a number greater than 4.2M (actually 2**32-1), it will NOT produce
the desired wait if you're using glbic 2.4. It you update HiRes to
V1.91 or greater it will. It seems that this is not a problem with
glibc 2.5 but it would be nice to hear some more confirmation about 2.5.
The following is from the change log for HiRes:
1.91 [2006-09-28]
- ualarm() in SuSE was overflowing after ~4.2 seconds,
probably due to a glibc bug, workaround by using the
setitimer() variant if either useconds or interval >= IV_1E6
(this case seems to vary between systems: are useconds
more than 999_999 for ualarm() defined or not)
Does this help?
-mark
------------------------------
Date: Sun, 13 Apr 2008 13:33:26 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: Time::HiRes < 1.91 and glibc 2.4 incompatibility
Message-Id: <375e4542-ac5d-4b0e-99ef-5124f7ee7f8a@f36g2000hsa.googlegroups.com>
On Apr 13, 10:18 am, Mark Seger <Mark.Se...@hp.com> wrote:
> smallpond wrote:
> > On Apr 12, 8:46 am, Mark Seger <Mark.Se...@hp.com> wrote:
> >> A long time ago I found a very peculiar timing bug in my open source
> >> performance monitoring tool 'collectl' - I discovered that when glibc
> >> went from version 2.3 to 2.4 it changed the time resolution from
> >> microseconds to nanoseconds, going from 32 bits to 64 bits. It also
> >> tuned out at the time the only one to make the move to that newer glibc
> >> was SuSE. Anyhow, that change broke Time::HiRes for any timing greater
> >> than 4.2 seconds!
>
> > What call into glibc changed?
>
> I honestly don't know the details. What I do know is if you call ualarm
> with a number greater than 4.2M (actually 2**32-1), it will NOT produce
> the desired wait if you're using glbic 2.4. It you update HiRes to
> V1.91 or greater it will. It seems that this is not a problem with
> glibc 2.5 but it would be nice to hear some more confirmation about 2.5.
>
> The following is from the change log for HiRes:
>
> 1.91 [2006-09-28]
> - ualarm() in SuSE was overflowing after ~4.2 seconds,
> probably due to a glibc bug, workaround by using the
> setitimer() variant if either useconds or interval >= IV_1E6
> (this case seems to vary between systems: are useconds
> more than 999_999 for ualarm() defined or not)
>
> Does this help?
>
> -mark
The useconds_t type is only defined to support values up to 1,000,000.
Depending on undefined behavior is a mistake on the caller's part.
The AIX C library also returns an error if values >1M are passed in;
it's not a glibc bug.
ualarm is replaced by setitimer, which has seconds and microseconds.
--S
------------------------------
Date: Mon, 14 Apr 2008 07:50:52 -0400
From: Mark Seger <Mark.Seger@hp.com>
To: smallpond <smallpond@juno.com>
Subject: Re: Time::HiRes < 1.91 and glibc 2.4 incompatibility
Message-Id: <4803451C.6020009@hp.com>
> The useconds_t type is only defined to support values up to 1,000,000.
> Depending on undefined behavior is a mistake on the caller's part.
> The AIX C library also returns an error if values >1M are passed in;
> it's not a glibc bug.
> ualarm is replaced by setitimer, which has seconds and microseconds.
> --S
When I first started using sigalrm in my tool many years ago, I was
testing on some redhat 7.2 systems as well as and redhat 9. I'm pretty
sure HiRes only called out time in usecs and didn't specify an upper
limit and it's just worked fine ever since until glibc 2.4. I'm not
sure what was changed internally but it still works just fine now as
long as you use a newer version of the module. There must be other
timer calls that do allow you to exceed 4.2 seconds because it wouldn't
make any sense to have a timer this accurate but not for longer
durations and so maybe HiRes determined which call to make based on your
request? Or maybe it just uses a call that does allow time >4.2 seconds?
All that said, I am very impressed with the accuracy of this timer
because I can literally get my code to within a clock tick of accuracy,
something I think is very lacking in most of the standard performance
monitoring tools - since many of them don't provide long term logging or
fine-grained timestamps, people just don't realize it.
-mark
------------------------------
Date: Tue, 15 Apr 2008 12:07:33 -0400
From: Mark Seger <Mark.Seger@hp.com>
Subject: Re: Time::HiRes < 1.91 and glibc 2.4 incompatibility
Message-Id: <fu2js8$a79$1@usenet01.boi.hp.com>
> The useconds_t type is only defined to support values up to 1,000,000.
> Depending on undefined behavior is a mistake on the caller's part.
> The AIX C library also returns an error if values >1M are passed in;
> it's not a glibc bug.
> ualarm is replaced by setitimer, which has seconds and microseconds.
> --S
I've been thinking about this some more, and I guess the question in my
mind is how did this ever work? pre HiRes .91, ularm of 10 seconds
works with glibc 2.3 and doesn't work with glibc 2.4.
Has nobody else tripped over this?
-mark
------------------------------
Date: Wed, 9 Apr 2008 14:34:21 -0700 (PDT)
From: ff0000 <ff0000.it@gmail.com>
Subject: Re: Trouble with @ARGV
Message-Id: <edfa0b07-1b95-4fd1-879d-837dccb806a8@s50g2000hsb.googlegroups.com>
Hi Ron,
> Personally, I'd use a module that is designed for retrieving command
> line options.
> Getopt::Longhttp://search.cpan.org/~jv/Getopt-Long-2.37/lib/Getopt/Long.pm
> Getopt::Simplehttp://search.cpan.org/~rsavage/Getopt-Simple-1.49/lib/Getopt/Simple.pm
Yes, i know them, but i try to avoid extra modules in order to have a
script that
runs with a standard Perl installation...
However Getopt::Simple seems really too simple, while Getopt::Long
lacks some features
i need (more powerfull callback usage per option, number of value per
options, ...).
That's all! :-)
See you and thank you again.
ff0000
------------------------------
Date: Wed, 9 Apr 2008 16:19:14 -0700 (PDT)
From: Ron Bergin <rkb@i.frys.com>
Subject: Re: Trouble with @ARGV
Message-Id: <83928a27-66aa-4483-a478-66e97f6263aa@u12g2000prd.googlegroups.com>
On Apr 9, 2:34 pm, ff0000 <ff0000...@gmail.com> wrote:
> Hi Ron,
>
> > Personally, I'd use a module that is designed for retrieving command
> > line options.
> > Getopt::Longhttp://search.cpan.org/~jv/Getopt-Long-2.37/lib/Getopt/Long.pm
> > Getopt::Simplehttp://search.cpan.org/~rsavage/Getopt-Simple-1.49/lib/Getopt/Simple.pm
>
> Yes, i know them, but i try to avoid extra modules in order to have a
> script that
> runs with a standard Perl installation...
That's a very short sided and IMO a bad guideline to follow.
BTW, both of those are core modules, so they do come with the standard
Perl installation.
http://perldoc.perl.org/index-modules-G.html
> However Getopt::Simple seems really too simple, while Getopt::Long
> lacks some features
What features do you feel it lacks?
Getopt::Simple is a wrapper for Getopt::long which provides a simple
interface. Are you saying that you don't like to use clean/simple
approaches that do the job well?
> i need (more powerfull callback usage per option, number of value per
> options, ...).
You can write your own callbacks sub that do anything you want, so how
is that not powerful enough?
------------------------------
Date: Wed, 09 Apr 2008 16:23:43 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Trouble with @ARGV
Message-Id: <090420081623432165%jimsgibson@gmail.com>
In article
<edfa0b07-1b95-4fd1-879d-837dccb806a8@s50g2000hsb.googlegroups.com>,
ff0000 <ff0000.it@gmail.com> wrote:
> Hi Ron,
>
> > Personally, I'd use a module that is designed for retrieving command
> > line options.
> > Getopt::Long
> > <http://search.cpan.org/~jv/Getopt-Long-2.37/lib/Getopt/Long.pm>
> >
> > Getopt::Simple
> > <http://search.cpan.org/~rsavage/Getopt-Simple-1.49/lib/Getopt/Simple.pm>
> Yes, i know them, but i try to avoid extra modules in order to have a
> script that
> runs with a standard Perl installation...
> However Getopt::Simple seems really too simple, while Getopt::Long
> lacks some features
> i need (more powerfull callback usage per option, number of value per
> options, ...).
Getopt::Long is included with modern Perl standard installations and is
quite powerful.
I do not know what you mean by "callback usage per option" or "number
of value per options". Your original example was parsing multiple
values of a single option, e.g. --opt=value1,value2,value3.
Getopt::Long can handle this in two ways. Firstly, as shown above and
then parsed with split:
GetOptions( "opt=s" => \$opt );
@args = split(/,/,$opt);
and used thusly:
test.pl --opt=value1,value2,value3
Secondly by putting any number of option values into an array:
my @args;
GetOptions( "opt=s" => \@args );
and called thusly:
test.pl --opt=value1 --opt=value2 --opt=value3
Perhaps if you are more clear about what it is that you are trying to
accomplish, someone can recommend alternative ways to do it.
--
Jim Gibson
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Wed, 9 Apr 2008 23:48:35 -0700 (PDT)
From: ff0000 <ff0000.it@gmail.com>
Subject: Re: Trouble with @ARGV
Message-Id: <e9f1de3d-e606-41a6-9f30-583685a8e368@m73g2000hsh.googlegroups.com>
Hi again :-),
> I do not know what you mean by "callback usage per option" or "number
> of value per options".
Oh, my damned bad english... Sorry, I'll try to explain in a better
way.
First of all i don't use any modules because i'm learning Perl and i
want,
for example, writing my own debugging module, options parsing
module, ...
(when i'll achieve a good point, i'll move into modules' world to
compare
and surely improve my code).
You could think i'm fool... Mmmmh... So i am :-)...
> Your original example was parsing multiple
> values of a single option, e.g. --opt=value1,value2,value3.
> Getopt::Long can handle this in two ways. Firstly, as shown above and
> then parsed with split:
>
> GetOptions( "opt=s" => \$opt );
> @args = split(/,/,$opt);
>
> and used thusly:
>
> test.pl --opt=value1,value2,value3
>
> Secondly by putting any number of option values into an array:
>
> my @args;
> GetOptions( "opt=s" => \@args );
>
> and called thusly:
>
> test.pl --opt=value1 --opt=value2 --opt=value3
I see these features yet.
> Perhaps if you are more clear about what it is that you are trying to
> accomplish, someone can recommend alternative ways to do it.
Our code handles options' features such min and max arguments per
options
and options' description (for automatic help building).
So it's a bit difficult to merge Getopt::Long with our features.
I hope i give you a better explanation this time.
Bye and thanks.
ff0000
------------------------------
Date: Wed, 9 Apr 2008 23:54:51 -0700 (PDT)
From: mike <mikaelpetterson@hotmail.com>
Subject: Uninitialized values in hash
Message-Id: <bf71241c-8a4f-4b55-8932-11e7e3899288@b1g2000hsg.googlegroups.com>
Hi,
I am running the following code:
use strict;
use warnings;
my $verbose = 1;
my $info = "[INFO] :";
my $error = "[ERROR]:";
my $configFile = "config.dat"; # Recommended plugins.
my %User_Preferences = ();
####################### Subroutines #######################
#################################### Start Main
#######################################
print "Reading configuration data ...\n";
open FILE, "$configFile" or die "$error Could not open file
$configFile :$! ";
while (<FILE>) {
s/\s+$//;# Remove all \r, \n, ^M from end of line
next if (/^$/);# ignore null lines
next if (/^\s*#/); # ignore comment line.
my ($config_name,$config_val)=split(/\s*=\s/, $_,2);# Split the line
$User_Preferences{$config_name}=$config_val;
$verbose && print "$config_name\n";
}
close FILE;
print "Deploying $User_Preferences{pathdeployunit}";
I get the following output:
Reading configuration data ...
asadminexecutable=C:\sailfin\b22\sailfin\bin>C:\sailfin\b22\sailfin\bin
\asadmin
passwordfile=C:\Documents and Settings\eraonel
\remote_admin_password.txt
user=admin
host=137.58.240.75
port=4848
pathdeployunit=M:\target\complete-ear-0.0.0.1-SNAPSHOT.ear
Use of uninitialized value in concatenation (.) or string at /vobs/
mbv_admin/tools/scripts/test/rdeploy.pl line 39.
Deploying
Compilation finished at Thu Apr 10 08:46:02
Question:
Is not the hash User_Preferences initialized with values when I read
my file? Is there another way to do it?
cheers,
//mike
------------------------------
Date: Thu, 10 Apr 2008 09:00:36 +0200
From: Frank Seitz <devnull4711@web.de>
Subject: Re: Uninitialized values in hash
Message-Id: <665s8pF2ier2oU3@mid.individual.net>
mike wrote:
> my ($config_name,$config_val)=split(/\s*=\s/, $_,2);# Split the line
^
\s*
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
------------------------------
Date: Thu, 10 Apr 2008 00:37:22 -0700 (PDT)
From: mike <mikaelpetterson@hotmail.com>
Subject: Re: Uninitialized values in hash
Message-Id: <904c150d-a6ea-4c65-bbb5-8c87b4642207@m36g2000hse.googlegroups.com>
On 10 Apr, 09:00, Frank Seitz <devnull4...@web.de> wrote:
> mike wrote:
> > my ($config_name,$config_val)=3Dsplit(/\s*=3D\s/, $_,2);# Split the line=
>
> ^
> \s*
> Frank
> --
> Dipl.-Inform. Frank Seitz;http://www.fseitz.de/
> Anwendungen f=FCr Ihr Internet und Intranet
> Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Thanks a lot for the concrete feedback!
//mike
------------------------------
Date: Thu, 10 Apr 2008 20:46:11 +0200
From: "Guido Ostkamp" <gueltig-bis-30-03-2008@nurfuerspam.de>
Subject: Re: Uninitialized values in hash
Message-Id: <js32d5-lm4.ln1@320076385420-0001.dialin.t-online.de>
mike <mikaelpetterson@hotmail.com> wrote:
> $verbose && print "$config_name\n";
>
> I get the following output:
>
> pathdeployunit=M:\target\complete-ear-0.0.0.1-SNAPSHOT.ear
>
> Is not the hash User_Preferences initialized with values when I read
> my file? Is there another way to do it?
Apparently the "split" did not work as expected, otherwise you would
no have got the output from the print above - the whole string is in
$config_name, and $config_val is undef, thus the warning.
Regards
Guido
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1449
***************************************
