Getopt::Long

2012-05-16 Thread Rajesh Saha
Hi,

In my program, I am using the module Getopt::Long

My intension is that if the user chooses --help, the program should show
the help message without bothering whether other options has been used or
not.

My program (say, test.pl) :

use Getopt::Long
my $abc;
my $help;

Getoptions ( abc=s = \$abc,
   help = \$help
 );

if ($help) { print This is help message\n ; exit ;}

if ($abc) { print You have choosen \abc\ as $abc };


If I run this:

1.test.pl -help
Output: This is help message

2. test.pl -abc ABC
Output : You have choosen abc as ABC

3. test.pl -abc -help
Output: You have choosen abc as -help

Out the above results 1  2 are fine, but 3 is not as I want. I understand
what's happening here [$abc is assigned as -help], but don't have idea
how to implement it properly so that in the 3rd it would print like  This
is help message .

Can anybody help please ?


Thanks n regards
Rajesh Saha


Re: Getopt::Long

2012-05-16 Thread Rajesh Saha
Hi,

Sorry for one typo. Read GetOptions in place of Getoptions .

Regards,
Rajesh



On Wed, May 16, 2012 at 2:39 PM, Rajesh Saha rajeshsaha...@gmail.comwrote:

 Hi,

 In my program, I am using the module Getopt::Long

 My intension is that if the user chooses --help, the program should show
 the help message without bothering whether other options has been used or
 not.

 My program (say, test.pl) :

 use Getopt::Long
 my $abc;
 my $help;

 Getoptions ( abc=s = \$abc,
help = \$help
  );

 if ($help) { print This is help message\n ; exit ;}

 if ($abc) { print You have choosen \abc\ as $abc };


 If I run this:

 1.test.pl -help
 Output: This is help message

 2. test.pl -abc ABC
 Output : You have choosen abc as ABC

 3. test.pl -abc -help
 Output: You have choosen abc as -help

 Out the above results 1  2 are fine, but 3 is not as I want. I understand
 what's happening here [$abc is assigned as -help], but don't have idea
 how to implement it properly so that in the 3rd it would print like  This
 is help message .

 Can anybody help please ?


 Thanks n regards
 Rajesh Saha




RE: Getopt::Long

2012-05-16 Thread Michael Brader
Hi,

Your problem is that Getopt::Long is consuming your -help as the argument to 
-abc before it can be recognised. You might be able to do something with the 
other Getopt::* modules, but the following piece of code will do what you want 
if you really need it:

use List::MoreUtils qw(any);
use Getopt::Long;

my $abc;
my $help;

if ( any { $_ eq '-help' } @ARGV ) {
$help = 1;
}

GetOptions (
abc=s = \$abc,
help = \$help
);

if ( $help ) { print This is help message\n ; exit ;}

if ($abc) { print You have choosen \abc\ as $abc };

# ==

If you don't have List::MoreUtils installed and can't install it, replace the 
'if ( any...)' block with:

foreach my $arg (@ARGV) {
if ( $arg eq '-help' ) {
$help = 1;
last;
}
}

Cheers,
Michael

-- 
Michael Brader
Senior Software Engineer - Billing
Techops - Softdev
Internode http://www.internode.on.net/


From: Rajesh Saha [rajeshsaha...@gmail.com]
Sent: Wednesday, 16 May 2012 6:39 PM
To: beginners@perl.org
Subject: Getopt::Long

Hi,

In my program, I am using the module Getopt::Long

My intension is that if the user chooses --help, the program should show
the help message without bothering whether other options has been used or
not.

My program (say, test.pl) :

use Getopt::Long
my $abc;
my $help;

Getoptions ( abc=s = \$abc,
   help = \$help
 );

if ($help) { print This is help message\n ; exit ;}

if ($abc) { print You have choosen \abc\ as $abc };


If I run this:

1.test.pl -help
Output: This is help message

2. test.pl -abc ABC
Output : You have choosen abc as ABC

3. test.pl -abc -help
Output: You have choosen abc as -help

Out the above results 1  2 are fine, but 3 is not as I want. I understand
what's happening here [$abc is assigned as -help], but don't have idea
how to implement it properly so that in the 3rd it would print like  This
is help message .

Can anybody help please ?


Thanks n regards
Rajesh Saha

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Getopt::Long

2012-05-16 Thread Brandon McCaig
On Wed, May 16, 2012 at 10:56:59AM +, Michael Brader wrote:
 Hi,

Hello:

 Your problem is that Getopt::Long is consuming your -help as
 the argument to -abc before it can be recognised. You might be
 able to do something with the other Getopt::* modules, but the
 following piece of code will do what you want if you really
 need it:
 
 use List::MoreUtils qw(any);
 use Getopt::Long;
 
 my $abc;
 my $help;
 
 if ( any { $_ eq '-help' } @ARGV ) {
 $help = 1;

Note that this doesn't account for '--help'. :) Besides, what if
'--help' happens to be a valid option argument? This would
prevent that from working. I think it's best to just keep with
the module's behavior and work normally. If a user wants --help
then they should generally /just/ say --help. If you want to do
some kind of option-specific help then specify --help before
--the-option:

  my-command --help --the-option

Or use non-option subcommands:

  my-command subcommand --help

Regards,


-- 
Brandon McCaig bamcc...@gmail.com bamcc...@castopulence.org
Castopulence Software https://www.castopulence.org/
Blog http://www.bamccaig.com/
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'



signature.asc
Description: Digital signature


Re: Getopt::Long

2012-05-16 Thread Manfred Lotz
Hi Rajesh,

On Wed, 16 May 2012 16:11:13 +0530
Rajesh Saha rajeshsaha...@gmail.com wrote:

 Hi,
 
 Sorry for one typo. Read GetOptions in place of Getoptions .
 
 Regards,
 Rajesh
 
 
 

Here is how I do it:


#! /usr/bin/perl

use strict;
use warnings;

use Getopt::Long;


my $dry_run = 0;

GetOptions('version|V' = sub { version(); exit; },
   'dry-run|n' = \$dry_run,
   'help|h' = sub { usage(); },
   ) or usage();


exit;


sub version {
print $0: Version 0.1\n;
exit;
}

sub usage {
print END_USAGE
Usage: $0 [ Options ]

This script does important work 

Options:
 -n, --dry-run  Simulates rsync commands
 -V, --version  Print version
 -h, --help This help
END_USAGE
;
exit;
  
return;
}



-- 
Manfred



-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Help with Getopt::Std

2011-10-22 Thread Peter Scott
On Sat, 22 Oct 2011 11:58:38 +1300, newbie01 perl wrote:
 Am just trying to port 1:1. Quite painful trying to figure out how to
 get awk-like behavior in Perl especially when trying to do some
 calculation on some specific fields.

Awk is Perl's closest ancestor on the evolutionary tree, from one point 
of view anyway.  There's even a program a2p that comes with perl (http://
perldoc.perl.org/a2p.html) for making transitioning automatic, if not 
easier.  Post what you're having trouble with here and we can help.

-- 
Peter Scott
http://www.perlmedic.com/ http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=0137001274
http://www.oreillyschool.com/certificates/perl-programming.php

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Help with Getopt::Std

2011-10-21 Thread newbie01 perl
Hi Brandon,

Thanks for your response.

Getopt::Std seems to be the simplest one, so am tryiing that one out first
:-) Am just trying to port 1:1. Quite painful trying to figure out how to
get awk-like behavior in Perl especially when trying to do some calculation
on some specific fields.

I've seen Getopt::Long and is checking on it right now. I gave up on it
before trying to follow how it works which is why I've flipped back to using
Getop::Std as I find it easier to follow. Need more exercises on hash
arrays and references I guess.

On Fri, Oct 21, 2011 at 5:07 PM, Brandon McCaig bamcc...@gmail.com wrote:

 On Thu, Oct 20, 2011 at 11:45 PM, newbie01 perl newbie01.p...@gmail.com
 wrote:
  Playing around with Getopt::Std as am trying to convert a UNIX
  Korn Shell Script to a Perl script.
 
  Is it possible to check for what are the values for opterr,
  optarg, optind?  How? :(-

 There are many Getopt:: packages. Perhaps you should look into
 other ones. :) Do you really need these variables you speak of or are you
 just trying to port 1:1?

 Personally, I use Getopt::Long because I like supporting long options as
 well. I don't think I've ever used them in Perl (probably in C), but I
 /think/ Getopt::Long supports those options (I'm too tired to check).

 The options that seem to work as I prefer them:

  use Getopt::Long qw/:config auto_help bundling no_auto_abbrev
  no_getopt_compat no_ignore_case_always no_require_order
  permute/;

 I don't care for guess what I meant software. I prefer software
 that does what you say and refuses to work when that doesn't make
 sense. ^^


 --
 Brandon McCaig bamcc...@gmail.com bamcc...@castopulence.org
 Castopulence Software https://www.castopulence.org/
 Blog http://www.bamccaig.com/
 perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
 q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
 tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'



Help with Getopt::Std

2011-10-20 Thread newbie01 perl
Hi all,

Playing around with Getopt::Std as am trying to convert a UNIX Korn Shell
Script to a Perl script.

Is it possible to check for what are the values for opterr, optarg, optind?
How? :(-

I've been Googling for quite sometime now and can't find an example of Perl
scripts that checks for opterr, optarg, optind and then do something with
them. Also, am trying to set opterr=0 so I don't get errors for when an
unknown option is provided. Is this possible or not possible?


/+  --- Script -- +/

#!/bin/perl -w

use strict;
use Getopt::Std;

##
# Some Variables #
##

# -
# How to check for the values of - opterr, optarg, optind - ???
# -

my $opterr=0;   # Supposed to turn off messages - ???
my $processid=$$;
my $header=;
my $size=;
my $filesystem=;
my %options=();

getopts( f:kgm , \%options );


# MAIN #


if ( $options{'g'} ) {
   $size=GB;
   $header=Filesystem GBytes Used Avail Capacity Mount
} elsif ( $options{'m'} ) {
   $size=MB;
   $header=Filesystem MBytes Used Avail Capacity Mount
} elsif ( $options{'k'} ) {
   $size=KB;
   $header=Filesystem KBytes Used Avail Capacity Mount
} else {
   $size=GB;
   $header=Filesystem GBytes Used Avail Capacity Mount
}

if ( $options{'f'} ) {
   $filesystem=$options{'f'};
}

print size = $size \n;
print header = $header \n;
print filesystem = $filesystem \n;
###
# THE END #
###
 /+  --- Sample RUN -- +/

server01$: ./opt-01.pl
size = GB
header = Filesystem GBytes Used Avail Capacity Mount
filesystem =
server01$: ./opt-01.pl -m
size = MB
header = Filesystem MBytes Used Avail Capacity Mount
filesystem =
*server01$: ./opt-01.pl -x
Unknown option: x  -- how to mask / hide this error/warning?
*size = GB
header = Filesystem GBytes Used Avail Capacity Mount
filesystem =
server01$: ./opt-01.pl -m -f /home/users
size = MB
header = Filesystem MBytes Used Avail Capacity Mount
filesystem = /home/users
Any help/feedback will be much appreciated. Thanks in advance.


Re: Help with Getopt::Std

2011-10-20 Thread Brandon McCaig
On Thu, Oct 20, 2011 at 11:45 PM, newbie01 perl newbie01.p...@gmail.com wrote:
 Playing around with Getopt::Std as am trying to convert a UNIX
 Korn Shell Script to a Perl script.

 Is it possible to check for what are the values for opterr,
 optarg, optind?  How? :(-

There are many Getopt:: packages. Perhaps you should look into
other ones. :) Do you really need these variables you speak of or are you
just trying to port 1:1?

Personally, I use Getopt::Long because I like supporting long options as
well. I don't think I've ever used them in Perl (probably in C), but I
/think/ Getopt::Long supports those options (I'm too tired to check).

The options that seem to work as I prefer them:

  use Getopt::Long qw/:config auto_help bundling no_auto_abbrev
  no_getopt_compat no_ignore_case_always no_require_order
  permute/;

I don't care for guess what I meant software. I prefer software
that does what you say and refuses to work when that doesn't make
sense. ^^


-- 
Brandon McCaig bamcc...@gmail.com bamcc...@castopulence.org
Castopulence Software https://www.castopulence.org/
Blog http://www.bamccaig.com/
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Not walking together with Getopt Module

2011-08-23 Thread Emeka
Hello All,

Why shouldn't this work?

use Getopt::Long;

#$debug = 0;



$result = GetOptions(age=i = $age);

if ($age) {print Input age is $age years; }

Emeka


-- 
*Satajanus  Nig. Ltd


*


Re: Not walking together with Getopt Module

2011-08-23 Thread Brandon McCaig
On Tue, Aug 23, 2011 at 5:53 PM, Emeka emekami...@gmail.com wrote:
 Hello All,

 Why shouldn't this work?
*snip*
 $result = GetOptions(age=i = $age);

You should always try to explain the results you expect and what you
are getting instead. I had a hard time understanding what your problem
was just from reading your message. :)

It looks like your problem is passing the value of $age instead of a
reference to $age. In order for the Getopt::Long module to modify your
$age variable it needs a reference to it:

use strict;
use warnings;

use Getopt::Long;

my $age;

my %opts = ('age=i' = \$age);

GetOptions(%opts) or exit 1;

if(defined $age)
{
print You specified '$age' years;
}

__END__

You can see perlref and perlreftut to learn about references. You
should also be using 'strict' and 'warnings' (to possibly save Shlomi
a breath ;).


-- 
Brandon McCaig http://www.bamccaig.com/ bamcc...@gmail.com
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software http://www.castopulence.org/ bamcc...@castopulence.org

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Getopt::Long in perl

2010-07-29 Thread Sooraj S
Hi,

I am using Getopt::Long to accept the command line arguments.

Logic
-
I have two mandatory options.
1.mod1_num
2.mod2_num

Both of them can accept either a 3digit number or another parameter
preserve which inturn accepts a 3digit number.

eg: my_script -mod1_num 123 -mod2_num 234
  my_script -mod1_num -preserve 123 mod2_num 234

If preserve is used with mod1_num it cannot be used with
mod2_num and viceversa.

How to do this with GetOptions? Please help me.


-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Getopt::Long in perl

2010-07-29 Thread Jim Gibson
On 7/29/10 Thu  Jul 29, 2010  1:17 AM, Sooraj S
soorajspadmanab...@gmail.com scribbled:

 Hi,
 
 I am using Getopt::Long to accept the command line arguments.
 
 Logic
 -
 I have two mandatory options.
 1.mod1_num
 2.mod2_num
 
 Both of them can accept either a 3digit number or another parameter
 preserve which inturn accepts a 3digit number.
 
 eg: my_script -mod1_num 123 -mod2_num 234
   my_script -mod1_num -preserve 123 mod2_num 234
 
 If preserve is used with mod1_num it cannot be used with
 mod2_num and viceversa.
 
 How to do this with GetOptions? Please help me.

The logic you want is unusual and will not be supported by Getopt::Long. I
believe you have two choices: 1) change the logic, 2) do the processing
yourself.

1. For more normal processing, combine the two options '-mod1_num -preserve'
into one (e.g., '-mod1_num_preserve') followed by the numerical argument.
This follows the normal logic supported by Getopt::Long.

2. If you can't change the logic, then process the command-line arguments
yourself with something like this (untested):

for( my $i = 0; $i  @ARGV; $i++ ) {
  if( $ARGV[$i] eq '-mod1_num' ) {
if( $ARGV[$i+1] eq '-preserve ) {
  $num = $ARGV[$i+2];
  $i += 2;
}else{
  $num = $ARGV[++$i];
}
  }elsif( $ARGV[$i] eq '-mod2_num' ) {
   ...
  }
}




-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




doubts in using Getopt in perl

2010-07-27 Thread Sooraj S
Hi,

I have a script which copies files from local machine to remote
machine.
parameteres : -d for directories, -f for files..

GetOptions ('d=s{,}' = \...@dir,
'f=s{,}' = \...@fil);

I want one more rename option -r which should be used only if -d
is specified ie only for directories... Please help me..


-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: doubts in using Getopt in perl

2010-07-27 Thread Jim Gibson
On 7/27/10 Tue  Jul 27, 2010  7:28 AM, Sooraj S
soorajspadmanab...@gmail.com scribbled:

 I have a script which copies files from local machine to remote
 machine.
 parameteres : -d for directories, -f for files..
 
 GetOptions ('d=s{,}' = \...@dir,
 'f=s{,}' = \...@fil);
 
 I want one more rename option -r which should be used only if -d
 is specified ie only for directories... Please help me..
 

Which Getopt module are you using? (there are 91 on CPAN). The syntax looks
like Getopt::Long, but it is better to be sure.

What is the logic for combining the -d and -r arguments? Can you give some
examples?

Obviously, the following will parse a -r option:

GetOptions ('d=s{,}' = \...@dir,
'f=s{,}' = \...@fil,
'r=s{,}' = \...@rename,
);

It is then up to you to apply the logic for combining the elements of @dir
and @rename, taking into account the possible presence of -f arguments. To
help further, we would need to know the logic involved.



-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




getopt::long

2010-07-06 Thread Unknown User
um,

I am pretty sure getopt::long keeps all input data in a hash, does
anybody know whether i can use that hash itself in my code, and if so,
how?

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: getopt::long

2010-07-06 Thread Octavian Rasnita

Hi,

use strict;
use warnings;
use Getopt::Long;

my %hash;
GetOptions(\%hash, first=s, second|s=s, third=i);

print $hash{first}, $hash{second}, $hash{third}, \n;

--
Octavian

- Original Message - 
From: Unknown User knowsuperunkn...@gmail.com

To: beginners beginners@perl.org
Sent: Tuesday, July 06, 2010 7:49 AM
Subject: getopt::long



um,

I am pretty sure getopt::long keeps all input data in a hash, does
anybody know whether i can use that hash itself in my code, and if so,
how?

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/



__ Information from ESET NOD32 Antivirus, version of virus 
signature database 5254 (20100706) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com






__ Information from ESET NOD32 Antivirus, version of virus signature 
database 5254 (20100706) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Getopt::Long

2010-06-17 Thread Unknown User
I have the following code:

GetOptions(
n|name=s =   \$name,
a|age=i = \$age,
s|sex=s = \$sex,
) || die Bad options\n;;

What i expected this code to do is to die if a bad option was given,
say -s without an arguement, as in ./myprog -n name -s -a 20
However, it does not do that.

What would be the correct method to die if one of the options is not complete?

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Getopt::Long

2010-06-17 Thread Chas. Owens
On Thu, Jun 17, 2010 at 02:36, Unknown User knowsuperunkn...@gmail.com wrote:
 I have the following code:

 GetOptions(
        n|name=s =   \$name,
        a|age=i = \$age,
        s|sex=s = \$sex,
 ) || die Bad options\n;;

 What i expected this code to do is to die if a bad option was given,
 say -s without an arguement, as in ./myprog -n name -s -a 20
 However, it does not do that.

 What would be the correct method to die if one of the options is not complete?


GetOptions should print a warning and return a false value in that
case.  What version of Perl and Getopt::Long are you using?  Try
running the following code.  If it does not die, then there is a
problem outside of your code.

#!/usr/bin/perl

use strict;
use warnings;

use Getopt::Long;

for my $args ([qw/-n a/], [-n]) {
@ARGV = @$args;
GetOptions(
n|name=s = \my $name,
a|age=s  = \my $age,
s|sex=s  = \my $sex
) or die bad options\n;
print [$name] @ARGV\n;
}



-- 
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Getopt::Long

2010-06-17 Thread Shawn H Corey

On 10-06-17 02:36 AM, Unknown User wrote:

I have the following code:

GetOptions(
n|name=s =  \$name,
a|age=i =  \$age,
s|sex=s =  \$sex,
) || die Bad options\n;;


GetOptions(
name=s =\$name,
age=i = \$age,
sex=s = \$sex,
) || die Bad options\n;

# GetOptions automatic determines which option by
# the minimum leading letters needed to
# distinguish them.



What i expected this code to do is to die if a bad option was given,
say -s without an arguement, as in ./myprog -n name -s -a 20
However, it does not do that.

What would be the correct method to die if one of the options is not complete?



But they are complete.  'name' is placed in $name, '-a' is placed in 
$sex, and @ARGV is left with ( '20' ).



--
Just my 0.0002 million dollars worth,
  Shawn

Programming is as much about organization and communication
as it is about coding.

The secret to great software:  Fail early  often.

Eliminate software piracy:  use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Getopt::Long

2010-06-17 Thread Chas. Owens
On Thu, Jun 17, 2010 at 07:50, Shawn H Corey shawnhco...@gmail.com wrote:
 On 10-06-17 02:36 AM, Unknown User wrote:

 I have the following code:

 GetOptions(
        n|name=s =   \$name,
        a|age=i =  \$age,
        s|sex=s =  \$sex,
 ) || die Bad options\n;;

 GetOptions(
        name=s =     \$name,
        age=i = \$age,
        sex=s = \$sex,
 ) || die Bad options\n;

 # GetOptions automatic determines which option by
 # the minimum leading letters needed to
 # distinguish them.


 What i expected this code to do is to die if a bad option was given,
 say -s without an arguement, as in ./myprog -n name -s -a 20
 However, it does not do that.

 What would be the correct method to die if one of the options is not
 complete?


 But they are complete.  'name' is placed in $name, '-a' is placed in $sex,
 and @ARGV is left with ( '20' ).
snip

Good point, try this:

#!/usr/bin/perl

use strict;
use warnings;

use Getopt::Long;

#to test, run with no args
unless (@ARGV) {
for my $args (
[ qw/-n name -a 5 -s M/ ],
[ qw/-n -a 5 -s M/  ],
[ qw/-n name -a a -s M/ ],
[ qw/-n name -a -s M/   ],
[ qw/-n name -a 5 -s W/ ],
[ qw/-n name/   ],
) {
print $0 @$args\n;
system $^X, $0, @$args;
print - x 5, \n\n;
}

print $0\n;
}

GetOptions(
n|name=s = \(my $name = DEFAULT),
a|age=n  = \(my $age  = DEFAULT),
s|sex=s  = \(my $sex  = DEFAULT),
) or die bad options\n;

my $errfmt = qq{Value %s invalid for option %s (%s)\n};

die sprintf $errfmt, $sex, -s, M or F expected
if length $sex and $sex =~ /^[^MF]$/;

die sprintf $errfmt, $name, -n, first character can't be a hyphen
if length $name and $name =~ /^-/;

print [$name] [$age] [$sex] @ARGV\n;



-- 
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/




Re: Getopt::Long

2010-06-17 Thread Robert Wohlfarth
On Thu, Jun 17, 2010 at 6:50 AM, Shawn H Corey shawnhco...@gmail.comwrote:

 On 10-06-17 02:36 AM, Unknown User wrote:

 I have the following code:

 GetOptions(
n|name=s =   \$name,
a|age=i =  \$age,
s|sex=s =  \$sex,
 ) || die Bad options\n;;


 But they are complete.  'name' is placed in $name, '-a' is placed in $sex,
 and @ARGV is left with ( '20' ).


Technically, -s does have a value: -a. GetOptions is treating -a as the
value for -s because the string -a immediately follows the option -s.
You could add validation on the value of -s. For example...

GetOptions(
   n|name=s =   \$name,
   a|age=i =  \$age,
   s|sex=s =  \$sex,
) || die Bad options\n;;

if ($sex !~ m/m(ale)?|f(emale)?/i) { die Invalid gender $sex\n; }

-- 
Robert Wohlfarth


Re: Getopt::Long and Log::StdLog problem

2008-08-05 Thread rafailowski

Rob Dixon wrote:

rafailowski wrote:
  

I have a problem with Getopt::Long and Log::StdLog.

An example script, i always have the following error :
Use of uninitialized value in hash element at 
/usr/local/share/perl/5.10.0/Log/StdLog.pm line 57


level = $cmd_args_ref-{log_level} is always undef(???) but
print $cmd_args_ref-{log_level}; return the good value

I try to fix this with BEGIN block (around GetOptions) with no success

Is there a way to solve this (BEGIN INIT block?)

#!/usr/bin/perl

use warnings;
use strict;
use Getopt::Long;

my %cmd_args = ();
my $cmd_args_ref = \%cmd_args;

GetOptions(
log-level=s   =  \$cmd_args{log_level},
);

sub log_format {
my ($date, $pid, $level, @message) = @_;
return [$date][$level]:  . join(q{}, @message);
};

use Log::StdLog {
format = \log_format,
file = $0.log,
level = $cmd_args_ref-{log_level},
};

print $cmd_args_ref-{log_level};



Calling GetOptions in a BEGIN block will work fine, but the initialisation of
$cmd_args_ref must be done at the same time, otherwise it won't be set up when
Log::StdLog comes to be imported. The code below should do what you want.

HTH,

Rob



use strict;
use warnings;

use Getopt::Long;

my (%cmd_args, $cmd_args_ref);

BEGIN {
  GetOptions(
'log-level=s' = \$cmd_args{log_level},
  );
  $cmd_args_ref = \%cmd_args;
}

sub log_format {
  my ($date, $pid, $level, @message) = @_;
  local $ = q{};
  return [$date][$level]: @message;
}

use Log::StdLog {
  format = \log_format,
  file = $0.log,
  level = $cmd_args_ref-{log_level},
};

print STDLOG user = HELLO\n;
  

Ohhh, it works fine!
thanks for your help...
rafailow

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Getopt::Long and Log::StdLog problem

2008-08-05 Thread rafailowski

Mr. Shawn H. Corey wrote:

On Mon, 2008-08-04 at 20:47 -0400, Mr. Shawn H. Corey wrote:
  

On Tue, 2008-08-05 at 01:33 +0200, rafailowski wrote:


Yes, without argument, the error is normal :

$ perl test.pl
Use of uninitialized value in hash element at 
/usr/local/share/perl/5.10.0/Log/StdLog.pm line 57.

Use of uninitialized value in string at test.pl line 25.

But with an argument like this :

$ perl test.pl --log-level=info
Use of uninitialized value in hash element at 
/usr/local/share/perl/5.10.0/Log/StdLog.pm line 57.

info

level = $cmd_args_ref-{log_level} stay undef and
print $cmd_args_ref-{log_level}; return the good value.

I don't understand why in : use Log::StdLog {...}, the value of 
$cmd_args_ref-{log_level} stay always undef???



  

Sorry, I was thinking about the problem correctly.  Try:

#!/usr/bin/perl
use Getopt::Long;
use Log::StdLog;

my %cmd_args = ();
my $cmd_args_ref = \%cmd_args;

GetOptions(
log-level=s   =  \$cmd_args{log_level},
);

sub log_format {
my ($date, $pid, $level, @message) = @_;
return [$date][$level]:  . join(q{}, @message);
};

Log::Stdlog::import( {
format = \log_format,
file = $0.log,
level = $cmd_args_ref-{log_level},
} );



Oops, try this instead:

Log::Stdlog::import {
format = \log_format,
file = $0.log,
level = $cmd_args_ref-{log_level},
};


  

print $cmd_args_ref-{log_level};

__END__

This re-runs the import function after the program has started.

--
Just my 0.0002 million dollars worth,
  Shawn

Where there's duct tape, there's hope.

Perl is the duct tape of the Internet.
Hassan Schroeder, Sun's first webmaster



Thx but adding __END__ return me this error, anyway the problem is solve 
with a BEGIN block (cf.Rob Dixon).


$ perl test.pl --log-level=debug
Name main::STDLOG used only once: possible typo at 
/usr/local/share/perl/5.10.0/Log/StdLog.pm line 51


Thx again.
rafailow.

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Getopt::Long and Log::StdLog problem

2008-08-05 Thread Mr. Shawn H. Corey
On Tue, 2008-08-05 at 08:57 +0200, rafailowski wrote:
 Thx but adding __END__ return me this error, anyway the problem is solve 
 with a BEGIN block (cf.Rob Dixon).
 
 $ perl test.pl --log-level=debug
 Name main::STDLOG used only once: possible typo at 
 /usr/local/share/perl/5.10.0/Log/StdLog.pm line 51
 
 Thx again.
 rafailow.
 

Adding __END__ will not create this warning.  It is because no other
statement has STDLOG in it.  When you use it, this warning shall go
away.  Example:

  print {*STDLOG} info printing to STDLOG\n;


-- 
Just my 0.0002 million dollars worth,
  Shawn

Where there's duct tape, there's hope.

Perl is the duct tape of the Internet.
Hassan Schroeder, Sun's first webmaster


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Getopt::Long and Log::StdLog problem

2008-08-05 Thread rafailowski

Mr. Shawn H. Corey wrote:

On Tue, 2008-08-05 at 08:57 +0200, rafailowski wrote:
  
Thx but adding __END__ return me this error, anyway the problem is solve 
with a BEGIN block (cf.Rob Dixon).


$ perl test.pl --log-level=debug
Name main::STDLOG used only once: possible typo at 
/usr/local/share/perl/5.10.0/Log/StdLog.pm line 51


Thx again.
rafailow.




Adding __END__ will not create this warning.  It is because no other
statement has STDLOG in it.  When you use it, this warning shall go
away.  Example:

  print {*STDLOG} info printing to STDLOG\n;

  

Yes you're right, it' works fine now.
Thx for your help.

rafailow.

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Getopt::Long and Log::StdLog problem

2008-08-04 Thread rafailowski

Hi all,

I have a problem with Getopt::Long and Log::StdLog.

An example script, i always have the following error :
Use of uninitialized value in hash element at 
/usr/local/share/perl/5.10.0/Log/StdLog.pm line 57


level = $cmd_args_ref-{log_level} is always undef(???) but
print $cmd_args_ref-{log_level}; return the good value

I try to fix this with BEGIN block (around GetOptions) with no success

Is there a way to solve this (BEGIN INIT block?)

#!/usr/bin/perl

use warnings;
use strict;
use Getopt::Long;

my %cmd_args = ();
my $cmd_args_ref = \%cmd_args;

GetOptions(
   log-level=s   =  \$cmd_args{log_level},
);

sub log_format {
   my ($date, $pid, $level, @message) = @_;
   return [$date][$level]:  . join(q{}, @message);
};

use Log::StdLog {
   format = \log_format,
   file = $0.log,
   level = $cmd_args_ref-{log_level},
};

print $cmd_args_ref-{log_level};

Thx in advance,
rafailow.

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Getopt::Long and Log::StdLog problem

2008-08-04 Thread Mr. Shawn H. Corey
On Tue, 2008-08-05 at 01:05 +0200, rafailowski wrote:
 Hi all,
 
 I have a problem with Getopt::Long and Log::StdLog.
 
 An example script, i always have the following error :
 Use of uninitialized value in hash element at 
 /usr/local/share/perl/5.10.0/Log/StdLog.pm line 57
 
 level = $cmd_args_ref-{log_level} is always undef(???) but
 print $cmd_args_ref-{log_level}; return the good value

$cmd_args_ref-{log_level} is undef unless you set with a command-line
argument.

 
 I try to fix this with BEGIN block (around GetOptions) with no success
 
 Is there a way to solve this (BEGIN INIT block?)
 
 #!/usr/bin/perl
 
 use warnings;
 use strict;
 use Getopt::Long;
 
 my %cmd_args = ();
 my $cmd_args_ref = \%cmd_args;
 
 GetOptions(
 log-level=s   =  \$cmd_args{log_level},
 );
 
 sub log_format {
 my ($date, $pid, $level, @message) = @_;
 return [$date][$level]:  . join(q{}, @message);
 };
 
 use Log::StdLog {
 format = \log_format,
 file = $0.log,
 level = $cmd_args_ref-{log_level},

level = ( $cmd_args_ref-{log_level} || 'none' ),

 };
 
 print $cmd_args_ref-{log_level};
 
 Thx in advance,
 rafailow.
 
-- 
Just my 0.0002 million dollars worth,
  Shawn

Where there's duct tape, there's hope.

Perl is the duct tape of the Internet.
Hassan Schroeder, Sun's first webmaster


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Getopt::Long and Log::StdLog problem

2008-08-04 Thread rafailowski

Mr. Shawn H. Corey wrote:

On Tue, 2008-08-05 at 01:05 +0200, rafailowski wrote:
  

Hi all,

I have a problem with Getopt::Long and Log::StdLog.

An example script, i always have the following error :
Use of uninitialized value in hash element at 
/usr/local/share/perl/5.10.0/Log/StdLog.pm line 57


level = $cmd_args_ref-{log_level} is always undef(???) but
print $cmd_args_ref-{log_level}; return the good value



$cmd_args_ref-{log_level} is undef unless you set with a command-line
argument.

  

I try to fix this with BEGIN block (around GetOptions) with no success

Is there a way to solve this (BEGIN INIT block?)

#!/usr/bin/perl

use warnings;
use strict;
use Getopt::Long;

my %cmd_args = ();
my $cmd_args_ref = \%cmd_args;

GetOptions(
log-level=s   =  \$cmd_args{log_level},
);

sub log_format {
my ($date, $pid, $level, @message) = @_;
return [$date][$level]:  . join(q{}, @message);
};

use Log::StdLog {
format = \log_format,
file = $0.log,
level = $cmd_args_ref-{log_level},



level = ( $cmd_args_ref-{log_level} || 'none' ),

  

};

print $cmd_args_ref-{log_level};

Thx in advance,
rafailow.



Yes, without argument, the error is normal :

$ perl test.pl
Use of uninitialized value in hash element at 
/usr/local/share/perl/5.10.0/Log/StdLog.pm line 57.

Use of uninitialized value in string at test.pl line 25.

But with an argument like this :

$ perl test.pl --log-level=info
Use of uninitialized value in hash element at 
/usr/local/share/perl/5.10.0/Log/StdLog.pm line 57.

info

level = $cmd_args_ref-{log_level} stay undef and
print $cmd_args_ref-{log_level}; return the good value.

I don't understand why in : use Log::StdLog {...}, the value of 
$cmd_args_ref-{log_level} stay always undef???



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Getopt::Long and Log::StdLog problem

2008-08-04 Thread Mr. Shawn H. Corey
On Tue, 2008-08-05 at 01:33 +0200, rafailowski wrote:
 Yes, without argument, the error is normal :
 
 $ perl test.pl
 Use of uninitialized value in hash element at 
 /usr/local/share/perl/5.10.0/Log/StdLog.pm line 57.
 Use of uninitialized value in string at test.pl line 25.
 
 But with an argument like this :
 
 $ perl test.pl --log-level=info
 Use of uninitialized value in hash element at 
 /usr/local/share/perl/5.10.0/Log/StdLog.pm line 57.
 info
 
 level = $cmd_args_ref-{log_level} stay undef and
 print $cmd_args_ref-{log_level}; return the good value.
 
 I don't understand why in : use Log::StdLog {...}, the value of 
 $cmd_args_ref-{log_level} stay always undef???
 
 

Sorry, I was thinking about the problem correctly.  Try:

#!/usr/bin/perl
use Getopt::Long;
use Log::StdLog;

my %cmd_args = ();
my $cmd_args_ref = \%cmd_args;

GetOptions(
log-level=s   =  \$cmd_args{log_level},
);

sub log_format {
my ($date, $pid, $level, @message) = @_;
return [$date][$level]:  . join(q{}, @message);
};

Log::Stdlog::import( {
format = \log_format,
file = $0.log,
level = $cmd_args_ref-{log_level},
} );

print $cmd_args_ref-{log_level};

__END__

This re-runs the import function after the program has started.

-- 
Just my 0.0002 million dollars worth,
  Shawn

Where there's duct tape, there's hope.

Perl is the duct tape of the Internet.
Hassan Schroeder, Sun's first webmaster


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Getopt::Long and Log::StdLog problem

2008-08-04 Thread Rob Dixon
rafailowski wrote:
 
 I have a problem with Getopt::Long and Log::StdLog.
 
 An example script, i always have the following error :
 Use of uninitialized value in hash element at 
 /usr/local/share/perl/5.10.0/Log/StdLog.pm line 57
 
 level = $cmd_args_ref-{log_level} is always undef(???) but
 print $cmd_args_ref-{log_level}; return the good value
 
 I try to fix this with BEGIN block (around GetOptions) with no success
 
 Is there a way to solve this (BEGIN INIT block?)
 
 #!/usr/bin/perl
 
 use warnings;
 use strict;
 use Getopt::Long;
 
 my %cmd_args = ();
 my $cmd_args_ref = \%cmd_args;
 
 GetOptions(
 log-level=s   =  \$cmd_args{log_level},
 );
 
 sub log_format {
 my ($date, $pid, $level, @message) = @_;
 return [$date][$level]:  . join(q{}, @message);
 };
 
 use Log::StdLog {
 format = \log_format,
 file = $0.log,
 level = $cmd_args_ref-{log_level},
 };
 
 print $cmd_args_ref-{log_level};

Calling GetOptions in a BEGIN block will work fine, but the initialisation of
$cmd_args_ref must be done at the same time, otherwise it won't be set up when
Log::StdLog comes to be imported. The code below should do what you want.

HTH,

Rob



use strict;
use warnings;

use Getopt::Long;

my (%cmd_args, $cmd_args_ref);

BEGIN {
  GetOptions(
'log-level=s' = \$cmd_args{log_level},
  );
  $cmd_args_ref = \%cmd_args;
}

sub log_format {
  my ($date, $pid, $level, @message) = @_;
  local $ = q{};
  return [$date][$level]: @message;
}

use Log::StdLog {
  format = \log_format,
  file = $0.log,
  level = $cmd_args_ref-{log_level},
};

print STDLOG user = HELLO\n;

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Getopt::Long and Log::StdLog problem

2008-08-04 Thread Mr. Shawn H. Corey
On Mon, 2008-08-04 at 20:47 -0400, Mr. Shawn H. Corey wrote:
 On Tue, 2008-08-05 at 01:33 +0200, rafailowski wrote:
  Yes, without argument, the error is normal :
  
  $ perl test.pl
  Use of uninitialized value in hash element at 
  /usr/local/share/perl/5.10.0/Log/StdLog.pm line 57.
  Use of uninitialized value in string at test.pl line 25.
  
  But with an argument like this :
  
  $ perl test.pl --log-level=info
  Use of uninitialized value in hash element at 
  /usr/local/share/perl/5.10.0/Log/StdLog.pm line 57.
  info
  
  level = $cmd_args_ref-{log_level} stay undef and
  print $cmd_args_ref-{log_level}; return the good value.
  
  I don't understand why in : use Log::StdLog {...}, the value of 
  $cmd_args_ref-{log_level} stay always undef???
  
  
 
 Sorry, I was thinking about the problem correctly.  Try:
 
 #!/usr/bin/perl
 use Getopt::Long;
 use Log::StdLog;
 
 my %cmd_args = ();
 my $cmd_args_ref = \%cmd_args;
 
 GetOptions(
 log-level=s   =  \$cmd_args{log_level},
 );
 
 sub log_format {
 my ($date, $pid, $level, @message) = @_;
 return [$date][$level]:  . join(q{}, @message);
 };
 
 Log::Stdlog::import( {
 format = \log_format,
 file = $0.log,
 level = $cmd_args_ref-{log_level},
 } );

Oops, try this instead:

Log::Stdlog::import {
format = \log_format,
file = $0.log,
level = $cmd_args_ref-{log_level},
};


 
 print $cmd_args_ref-{log_level};
 
 __END__
 
 This re-runs the import function after the program has started.
 
 -- 
 Just my 0.0002 million dollars worth,
   Shawn
 
 Where there's duct tape, there's hope.
 
 Perl is the duct tape of the Internet.
 Hassan Schroeder, Sun's first webmaster
 
 
-- 
Just my 0.0002 million dollars worth,
  Shawn

Where there's duct tape, there's hope.

Perl is the duct tape of the Internet.
Hassan Schroeder, Sun's first webmaster


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Getopt::Std and warnings

2007-12-14 Thread reader
I want a warning message without having to do special coding with
Getopt::Std. 

I'd like for options passed to getops() note the plural with the (:)
colon to give a warning message or even possibly die (Haven't
decided that yet) if no argument accompanies them.

But first: The Getopt::Std documentation doesn't say that will happen
but I wondered if it is supposed to or can be made to easily before I
add my own coding.

I can figure out several ways to accomplish my goal but any advice
will be appreciated.

With the script included below; passing a cmdline like 

 ./getoptschk.pl  -a -b -c

Doesn't give any warnings.  
The code passed:  `$optstr =abc:'
does indicate there should be an accompanying argument with opt_c

The code is kind of silly but in addition to seeing what would happen
when -c was not given an argument... I was also checking what happened
to any argument on the cmdline.

(This is not a question or complaint)
A secondary suprise was seeing that ARGV is reported as empty at each
stop.  Getopt must slurp all dashed letters at once and shift them off
of ARGV. 

Anyway with this cmdline 

   ./getoptchk.pl -a -b  -c

no warnings occur

Also I noticed passing a completely unexpected dashed argument doesn't
produce a warning either.

  ./getoptchk.pl -a -b  -c -d arg1 arg2

No warnings  
and I think this should have according to perldoc
Getopt::Std:
[... in part]

   The getopts() function is similar, but you should pass to it
   the list of all switches to be recognized.  If unspecified
   switches are found on the command-line, the user will be warned
   that an unknown option was given.

[...]

But there is more in `perldoc Getopt::Std' that may explain it but
I'll confess I didn't understand that part and I think it only applied
to using --help and --version.. (I've included an abridged
version of that section after the code)



#!/usr/local/bin/perl

use strict;
use warnings;
use Getopt::Std;

our ($opt_a, $opt_b, $opt_c );
my $optstr =abc:;
getopts($optstr);

if($opt_a){
   print Yeah opt_a ARGV is @ARGV\n;
}
if($opt_b){
   print Yeah opt_b ARGV is @ARGV\n;
}
if($opt_c){
   print Yeah opt_c ARGV is @ARGV\n;
   ## I think the -c is shifted off already but lets see
   print Yeah opt_c argument $opt_c ARGV is @ARGV\n;
}
if(@ARGV){
   print  All opts complete ARGV is now:
 @ARGV\n;
}


From perldoc Getopt::Std
[...]

--help and --version

[...] snipped first and second paragraph

   Note that due to excessive paranoia, if $Getopt::Std::STAN-
   DARD_HELP_VERSION isn't true (the default is false), then the
   messages are printed on STDERR, and the processing continues
   after the messages are printed.  This being the opposite of the
   standard-conforming behav- iour, it is strongly recommended to
   set $Getopt::Std::STAN- DARD_HELP_VERSION to true.


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Getopt::Std and warnings

2007-12-14 Thread John W . Krahn
On Friday 14 December 2007 09:09, [EMAIL PROTECTED] wrote:

 I want a warning message without having to do special coding with
 Getopt::Std.

Getopt is one of those itches that a lot of people have felt like 
scratching:

http://search.cpan.org/search?query=getoptmode=module

If Getopt::Std or Getopt::Long do not fill the bill then perhaps one of 
the fifty or sixty other Getopt modules will do what you want.



John
-- 
use Perl;
program
fulfillment

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Getopt::Std and warnings

2007-12-14 Thread reader
John W.Krahn [EMAIL PROTECTED] writes:

 On Friday 14 December 2007 09:09, [EMAIL PROTECTED] wrote:

 I want a warning message without having to do special coding with
 Getopt::Std.

 Getopt is one of those itches that a lot of people have felt like 
 scratching:

 http://search.cpan.org/search?query=getoptmode=module

 If Getopt::Std or Getopt::Long do not fill the bill then perhaps one of 
 the fifty or sixty other Getopt modules will do what you want.

Egad, I had no idea... never occured to me to look for more getopts
stuff than Std and Long.

Looks like `Getopt::Easy' might merit trying.  Says it has quite a
few ways to make it output errors or warnings.. The only drawback, just
from reading the synopsis, appears to be that few of the letters are
spoken for, depending on what Getopt::Easy you set.  But with 46 or so
others ... I think I might be able to work around that
limitation... hehe.

Do you have one you like? Or some other way to accomplish that kind of
while/case setup? 


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: What happened to Getopt::Std ?

2007-06-14 Thread Miguel Santinho
Em (On) Wed, Jun 13, 2007 at 09:29:27AM -0400, John Peacock escreveu (wrote):
  The Kurila project is a fork of Perl5 without the strict backwards 
 compatibility required of v5.10.0, as a theoretical experiment.  You'll note 
 now that under CPAN, it shows up as

Is CPAN (Comprehensive __Perl__ Archive Network) the right place to put
projects that are forks of Perl, and respectives modules?

Miguel



pgpLN7fIiJaIg.pgp
Description: PGP signature


What happened to Getopt::Std ?

2007-06-13 Thread Jorge Almeida

http://search.cpan.org/search?m=moduleq=getopts=21



--
Jorge Almeida

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: What happened to Getopt::Std ?

2007-06-13 Thread Mumia W.

On 06/13/2007 03:03 AM, Jorge Almeida wrote:

http://search.cpan.org/search?m=moduleq=getopts=21





Hmm: http://search.cpan.org/~tty/kurila-0_02/

Hmm: http://search.cpan.org/src/TTY/kurila-0_02/

It looks like this person, TTY, uploaded a modified version of Perl to 
his/her CPAN directory. For virtually every module in Perl 5, there is a 
rouge version provided by TTY.


I don't know what is going on. It smells like an attempt to compromise 
people's systems, although it could be a mistake.


Even if it is a mistake, it's a big one--one that the PAUSE maintainers 
should not overlook. Incompetence on this scale is a danger to CPAN.



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: What happened to Getopt::Std ?

2007-06-13 Thread Miguel Santinho
Em (On) Wed, Jun 13, 2007 at 09:03:09AM +0100, Jorge Almeida escreveu (wrote):
  http://search.cpan.org/search?m=moduleq=getopts=21

What is this Perl Kurila? and why is this (apparently) creating conflicts
with some namespaces?
http://search.cpan.org/~tty/kurila-0_02/

Miguel



pgprv5pnkRfrR.pgp
Description: PGP signature


Re: What happened to Getopt::Std ?

2007-06-13 Thread Mumia W.

On 06/13/2007 08:29 AM, John Peacock wrote:

Mumia W. wrote:
I don't know what is going on. It smells like an attempt to compromise 
people's systems, although it could be a mistake.


Then maybe you should use Google or even look at the distro, before 
making wild accusations:


http://www.nntp.perl.org/group/perl.perl5.porters/2007/04/msg123813.html
http://search.cpan.org/src/TTY/kurila-0_02/README

The Kurila project is a fork of Perl5 without the strict backwards 
compatibility required of v5.10.0, as a theoretical experiment.  You'll 
note now that under CPAN, it shows up as


** UNAUTHORIZED RELEASE **

which should make it highly unlikely that someone will install it by 
accident.


John



mea culpa



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: What happened to Getopt::Std ?

2007-06-13 Thread John Peacock

Mumia W. wrote:
I don't know what is going on. It smells like an attempt to compromise 
people's systems, although it could be a mistake.


Then maybe you should use Google or even look at the distro, before 
making wild accusations:


http://www.nntp.perl.org/group/perl.perl5.porters/2007/04/msg123813.html
http://search.cpan.org/src/TTY/kurila-0_02/README

The Kurila project is a fork of Perl5 without the strict backwards 
compatibility required of v5.10.0, as a theoretical experiment.  You'll 
note now that under CPAN, it shows up as


** UNAUTHORIZED RELEASE **

which should make it highly unlikely that someone will install it by 
accident.


John

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Paths, Spaces, Getopt::Long

2007-06-03 Thread Mike Lesser
Hi all. I have a problem that _must_ have a very simple solution  
(that I can't find).


I use the module Getopt::Long to read arguments, one of which is a  
file path that may have spaces. The path string that is returned from  
Getopt has spaces without escape chars.  The string seems to be fine  
for Perl use, but not so great for other things, such as the Shell  
module, which can't handle the spaces.


I have to assume that paths can be converted easily for use in shells  
and such, without resorting to RegEx. Any ideas?


Mike



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Paths, Spaces, Getopt::Long

2007-06-03 Thread Tom Phoenix

On 6/3/07, Mike Lesser [EMAIL PROTECTED] wrote:


I use the module Getopt::Long to read arguments, one of which is a
file path that may have spaces. The path string that is returned from
Getopt has spaces without escape chars.  The string seems to be fine
for Perl use, but not so great for other things, such as the Shell
module, which can't handle the spaces.


So, the problem isn't that Getopt::Long is giving you the correct file
name, which happens to contain spaces. The problem is that you're
passing a string containing shell metacharacters (spaces) to the
shell. Yes?

I fear that you're using the Shell module for more than it was
intended to do, perhaps because you don't know about system().

One easy solution may be to give a list of arguments to system(). The
first is the name of the program you're trying to run, the rest of the
list are the command-line arguments to give it. You don't need to
escape anything, because the strings are passed as-is.

 # use the system's chmod command on a list of filenames
 system chmod, u+w, @filenames;

Hope this helps!

--Tom Phoenix
Stonehenge Perl Training

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Paths, Spaces, Getopt::Long

2007-06-03 Thread Chas Owens

On 6/3/07, Mike Lesser [EMAIL PROTECTED] wrote:
snip

I have to assume that paths can be converted easily for use in shells
and such, without resorting to RegEx. Any ideas?

snip

Aside from the multi argument version of system that Tom has already
mentioned, the bigger question is Why are you running code outside of
Perl?  Often people think they need to say things like

system rm -rf $path;
system mkdir $path;
system chmod 666 $path;

when they could just as easily say

use File::Path;
use File::chmod;

rmtree $path;
mkpath $path;
chmod 0666, $path;

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Fwd: Paths, Spaces, Getopt::Long

2007-06-03 Thread Mike Lesser


Well I'm not sure. I may be explaining this badly. I'll go thru all  
the details in case it helps.


The path I pass when I'm executing the script is escaped, which I  
assume is correct.


Once that path is read by Getopt, I print it and, voila, no escapes,  
just nice-to-read spaces.


This path gets a filename appended as if it were a regular string,  
and is used to when I make a file (via another module). This file is  
created  written just fine. This made me assume all was well, and  
that Perl or the modules covered all the issues with spaces. I now  
realize this may have been naive.


Then I attempted to use Tidy, sans HTML::Tidy, through Shell. The  
HTML::Tidy lib won't work on my system. So, I have been futzing with  
tidy and I'v e discovered that tidy and simple commands like cd fail,  
most likely because of the spaces in my paths.


For example, here's the path I pass to the script (no quotes):
/Users/mike/Airline\ Sheets/Original\ Schedules/UnitedJune.html

Here's the path as found via File::Basename/fileparse:
/Users/mike/Projects/Omni/Airline Sheets/Original Schedules/

My script uses modules that create files based on this path, and it  
seems okay. If however I try to  use the path with say,  
the Shell mod, it fails. This is what cd returns:


/Users/mike/Projects/Omni/Airline: No such file or directory
.
I need to use the Shell because I need to run tidy, locally.


I fear that you're using the Shell module for more than it was
intended to do, perhaps because you don't know about system().



That may very well be the case!

One easy solution may be to give a list of arguments to system(). The
first is the name of the program you're trying to run, the rest of the
list are the command-line arguments to give it. You don't need to
escape anything, because the strings are passed as-is.

 # use the system's chmod command on a list of filenames
 system chmod, u+w, @filenames;

Hope this helps!

--Tom Phoenix
Stonehenge Perl Training




--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Fwd: Paths, Spaces, Getopt::Long

2007-06-03 Thread Mike Lesser



Begin forwarded message:

From: Mike Lesser [EMAIL PROTECTED]
Date: June 3, 2007 3:48:56 PM EDT
To: Chas Owens [EMAIL PROTECTED]
Subject: Re: Paths, Spaces, Getopt::Long

On Jun 3, 2007, at 1:59 PM, Chas Owens wrote:


On 6/3/07, Mike Lesser [EMAIL PROTECTED] wrote:
snip

I have to assume that paths can be converted easily for use in shells
and such, without resorting to RegEx. Any ideas?

snip

Aside from the multi argument version of system that Tom has already
mentioned, the bigger question is Why are you running code outside of
Perl?  Often people think they need to say things like



The script needs to use tidy to strip garbage from an html file prior  
to reading it. It's a file automatically generated by another company  
and it's filled with junk, hence no chance to fix it at the source.


The HTML::Tidy module would be fine but it doesn't pass testing on my  
box, and won't work with a forced install. I took a look and found  
that that seems to be a recurring problem on OS X 10.4. I haven't yet  
looked thru the code to determine the source of the problem as it  
seemed that running either Shell or system () was an interesting  
thing to learn. I might have been wrong there!


I've had success running hard coded paths and stuff, but now see that  
there's this space problem, which I didn't realize since Perl was  
handling paths nicely all by itself!




system rm -rf $path;
system mkdir $path;
system chmod 666 $path;

when they could just as easily say

use File::Path;
use File::chmod;

rmtree $path;
mkpath $path;
chmod 0666, $path;




--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Paths, Spaces, Getopt::Long

2007-06-03 Thread Mike Lesser


On Jun 3, 2007, at 1:59 PM, Chas Owens wrote:


On 6/3/07, Mike Lesser [EMAIL PROTECTED] wrote:
snip

I have to assume that paths can be converted easily for use in shells
and such, without resorting to RegEx. Any ideas?

snip

Aside from the multi argument version of system that Tom has already
mentioned, the bigger question is Why are you running code outside of
Perl?  Often people think they need to say things like

system rm -rf $path;
system mkdir $path;
system chmod 666 $path;



My intent is to keep it within Perl, but I seem to be going further  
outside of it due to this problem. I'm involved in all sorts of Perl- 
unrelated nonsense.


I've taken another look at HTML::Tidy, and it appears that there are  
some critical issues with the version of tidylib that's on Mac OS X,  
including the version number. Tidy's included, which is nice, but  
fink is intent on keeping the same (old) version.


I figure, get the latest from CVS, but there's been some problems  
there (probably due to me having never used it before). Rebuilding a  
new version of the lib hasn't been successful yet due to a variety of  
problems (but I may solve them tonite). Thus writing an Xsub to it  
(another thing for me to learn) seems excessive. Now I'm really far out!


Roadblocks everywhere!

I'm thinking that a little RegEx might just serve me better even  
though it's reinventing the wheel. This script is intended for use  
with a file from a specific vendor, which has it's own quirks (it  
looks like someone set it an exporter 10 years ago and then left the  
company) that make no sense. It's not _so_ bad to make some custom  
code, is it? Yuck.





--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Paths, Spaces, Getopt::Long

2007-06-03 Thread Chas Owens

On 6/3/07, Mike Lesser [EMAIL PROTECTED] wrote:
snip

Then I attempted to use Tidy, sans HTML::Tidy, through Shell. The
HTML::Tidy lib won't work on my system. So, I have been futzing with
tidy and I'v e discovered that tidy and simple commands like cd fail,
most likely because of the spaces in my paths.

For example, here's the path I pass to the script (no quotes):
 /Users/mike/Airline\ Sheets/Original\ Schedules/UnitedJune.html

Here's the path as found via File::Basename/fileparse:
 /Users/mike/Projects/Omni/Airline Sheets/Original Schedules/

snip

What you want is

my $tidy = /usr/bin/tidy;
my @tidy_args = qw(--foo --bar -- example);
my $path = get_path();
my $file = $path . get_file();

system($tidy, @tidy_args, $file);

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Paths, Spaces, Getopt::Long

2007-06-03 Thread Chas Owens

On 6/3/07, Chas Owens [EMAIL PROTECTED] wrote:
snip

my $tidy = /usr/bin/tidy;
my @tidy_args = qw(--foo --bar -- example);
my $path = get_path();
my $file = $path . get_file();

system($tidy, @tidy_args, $file);


Opps, forgot the error checking.

system($tidy, @tidy_args, $file)
   or die qq($tidy @tidy_args $file failed: $?;

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Paths, Spaces, Getopt::Long

2007-06-03 Thread Chas Owens

On 6/3/07, Chas Owens [EMAIL PROTECTED] wrote:

On 6/3/07, Chas Owens [EMAIL PROTECTED] wrote:
snip
 my $tidy = /usr/bin/tidy;
 my @tidy_args = qw(--foo --bar -- example);
 my $path = get_path();
 my $file = $path . get_file();

 system($tidy, @tidy_args, $file);

Opps, forgot the error checking.

system($tidy, @tidy_args, $file)
or die qq($tidy @tidy_args $file failed: $?;



I will get it right, I swear.

system($tidy, @tidy_args, $file)
   or die qq($tidy @tidy_args $file failed: $?);

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Paths, Spaces, Getopt::Long

2007-06-03 Thread Mike Lesser

Okay, I eliminated the tidy with some more robust regex. D'oh!

Case closed!

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: Paths, Spaces, Getopt::Long

2007-06-03 Thread John W. Krahn
Chas Owens wrote:

 On 6/3/07, Chas Owens [EMAIL PROTECTED] wrote:
 On 6/3/07, Chas Owens [EMAIL PROTECTED] wrote:
 snip
  my $tidy = /usr/bin/tidy;
  my @tidy_args = qw(--foo --bar -- example);
  my $path = get_path();
  my $file = $path . get_file();
 
  system($tidy, @tidy_args, $file);

 Opps, forgot the error checking.

 system($tidy, @tidy_args, $file)
 or die qq($tidy @tidy_args $file failed: $?;

 
 I will get it right, I swear.
 
 system($tidy, @tidy_args, $file)
 or die qq($tidy @tidy_args $file failed: $?);

This should work better:

system($tidy, @tidy_args, $file) == 0
or die qq($tidy @tidy_args $file failed: $?);

Or:

system($tidy, @tidy_args, $file)
and die qq($tidy @tidy_args $file failed: $?);



John
-- 
Perl isn't a toolbox, but a small machine shop where you can special-order
certain sorts of tools at low cost and in short order.   -- Larry Wall

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: getopt

2007-01-24 Thread Tom Phoenix

On 1/23/07, Tony Heal [EMAIL PROTECTED] wrote:


The end process will be myscript.pl -rf /home/myfolder and that will pass
the -rf and /home/myfolder arguments to the rm command after copying
everything to the trashcan.


Why not simply move things to the trashcan, and skip rm altogether?


The script as is gets an error when run. My problem is how to make the
argument '-rf' pass to the system() command then I plan to use ARGV[0] to
pass the directory.


Maybe I don't understand you correctly. But @ARGV is used for passing
arguments into your Perl program, not to another program. Pass the
system() command any arguments you'd like, though.


$options = `print @option`;


Are you running an external program called print? What does it output?
Maybe you meant to use Perl's print operator, or something else?

   $options = @option;# maybe this?

   $options = join , @option;# or this?


system(ls -$options);


Why are you using ls?

Hope this helps!

--Tom Phoenix
Stonehenge Perl Training

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




Re: getopt

2007-01-24 Thread Chad Perrin
On Wed, Jan 24, 2007 at 06:53:53AM -0800, Tom Phoenix wrote:
 
 Why not simply move things to the trashcan, and skip rm altogether?

Yeah . . . I'd probably solve this problem by using the mv command.  If
you really wanted to, you could just write a shell or Perl script called
trash that moved files specified on the command line to a hardcoded
trashcan directory.  Why recreate rm just to add a single command line
option?

. . . and why not recreate it in C (or something vaguely equivalent) if
that's what you want to do, anyway?  If you really think it's important
enough, maybe you could make a case for that functionality being added
to the version of rm included with core utilities on your system.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
There comes a time in the history of any project when it becomes necessary
to shoot the engineers and begin production. - MacUser, November 1990

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/




getopt

2007-01-23 Thread Tony Heal
I found an example using getopt on the web and I am trying to convert it to
my use.  Everything works except the last part. What  am attempting to do is
create a script which I can pass switches as arguments. Eventually this
script will replace the rm command on my linux server, so that I can create
a trashcan.

 

The end process will be myscript.pl -rf /home/myfolder and that will pass
the -rf and /home/myfolder arguments to the rm command after copying
everything to the trashcan.

 

The script as is gets an error when run. My problem is how to make the
argument '-rf' pass to the system() command then I plan to use ARGV[0] to
pass the directory.

 

 

 

 

#!/usr/bin/perl

 

use warnings;

use strict;

 

use vars qw/ %opt /;

sub init()

{

use Getopt::Std;

my $opt_string = 'adfirv';

getopts( $opt_string, \%opt ) or usage();

usage() if $opt{h};

}

 

sub usage()

{

print STDERR EOF;

 

This program does...

 

usage: $0 [-adfirv] [-f file]

 

bla bla bla

example: $0 -adfirv file

 

EOF

exit;

}

 

init();

 

my @option;

my $options;

 

push @option = a if $opt{a};

push @option = d if $opt{d};

push @option = f if $opt{f};

push @option = i if $opt{i};

push @option = r if $opt{r};

push @option = v if $opt{v};

 

$options = `print @option`;

system(ls -$options);

print \n;



RE: Getopt::Std producing unexpected results

2006-12-19 Thread RICHARD FERNANDEZ
 

 Getopt::Std only works with single hyphen switches, the only 
 exceptions being '--', '--help' and '--version'.
 
 perldoc Getopt::Std
 
 
 Getopt::Std also processes swithes in clusters so -abcd 
 filename is the same as -a -b -c -d filename.
 
 
 With your command line:
 
 ./mytest.pl -h localhost -l file --volgroups foo bar
 
 First the '-h' switch is processed and 'localhost' is 
 assigned to $opt_h.
 Next the '-l' switch is processed and 'file' is assigned to 
 $opt_l.  Next the cluster '--volgroups' is processed as the 
 switches '--', '-v', '-o' and '-l'
 and since '-l' takes a value the remaining string 'groups' is 
 assigned to $opt_l overwriting the previous value in $opt_l.
 
 
 
 
 John
 --


Ahhh I see.

Thanks for the clarification, John!

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Getopt::Std producing unexpected results

2006-12-18 Thread RICHARD FERNANDEZ
Hi Folks,

I've written a little mytest.pl using Getopt::Std:

script
#!/usr/bin/perl
use warnings;
use strict;
use Getopt::Std;

getopt('hl');
our ($opt_h, $opt_l);

my $hostname = $opt_h ? $opt_h : undef;
my $file = $opt_l ? $opt_l : undef;
my @volgroups   = @ARGV;


print hostname = $hostname\n;
print file = $file\n;
print volgroups = , join(\t, @volgroups), \n;

/script

When I run this, I get the following output:

$ ./mytest.pl -h localhost -l file foo bar
hostname = localhost
file = file
volgroups = foo bar

This is what I expect. If I then add --volgroups before the foo,
I get this:

$ ./mytest.pl -h localhost -l file --volgroups foo bar
hostname = localhost
file = groups
volgroups = foo bar

I would have expected the second output to be the same as the first.
Specifically, I can't see why file now equals groups.

The man page says that:
To allow programs to process arguments that look like
 switches, but aren't, both functions will stop processing
 switches when they see the argument --.  The -- will
 be removed from @ARGV.

Interestingly enough, if I say --volgroup instead of --volgroups, then
the output says file = group instead of file = groups!

Can anyone shed some light?
Thanks!

richf





--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Getopt::Std producing unexpected results

2006-12-18 Thread John W. Krahn
RICHARD FERNANDEZ wrote:
 Hi Folks,

Hello,

 I've written a little mytest.pl using Getopt::Std:
 
 script
 #!/usr/bin/perl
 use warnings;
 use strict;
 use Getopt::Std;
 
 getopt('hl');
 our ($opt_h, $opt_l);
 
 my $hostname = $opt_h ? $opt_h : undef;
 my $file = $opt_l ? $opt_l : undef;
 my @volgroups   = @ARGV;
 
 
 print hostname = $hostname\n;
 print file = $file\n;
 print volgroups = , join(\t, @volgroups), \n;
 
 /script
 
 When I run this, I get the following output:
 
 $ ./mytest.pl -h localhost -l file foo bar
 hostname = localhost
 file = file
 volgroups = foo bar
 
 This is what I expect. If I then add --volgroups before the foo,
 I get this:
 
 $ ./mytest.pl -h localhost -l file --volgroups foo bar
 hostname = localhost
 file = groups
 volgroups = foo bar
 
 I would have expected the second output to be the same as the first.
 Specifically, I can't see why file now equals groups.
 
 The man page says that:
 To allow programs to process arguments that look like
  switches, but aren't, both functions will stop processing
  switches when they see the argument --.  The -- will
  be removed from @ARGV.
 
 Interestingly enough, if I say --volgroup instead of --volgroups, then
 the output says file = group instead of file = groups!
 
 Can anyone shed some light?

Getopt::Std only works with single hyphen switches, the only exceptions being
'--', '--help' and '--version'.

perldoc Getopt::Std


Getopt::Std also processes swithes in clusters so -abcd filename is the same
as -a -b -c -d filename.


With your command line:

./mytest.pl -h localhost -l file --volgroups foo bar

First the '-h' switch is processed and 'localhost' is assigned to $opt_h.
Next the '-l' switch is processed and 'file' is assigned to $opt_l.  Next the
cluster '--volgroups' is processed as the switches '--', '-v', '-o' and '-l'
and since '-l' takes a value the remaining string 'groups' is assigned to
$opt_l overwriting the previous value in $opt_l.




John
-- 
Perl isn't a toolbox, but a small machine shop where you can special-order
certain sorts of tools at low cost and in short order.   -- Larry Wall

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




hwo to configure the Getopt:::STD options for command line arguments.

2006-10-16 Thread perl pra

hi All,


I have to call some perl scripts with command line arguements from another
perl script.

(some thing like this)

perl -s  -a  $ENV{X}  -b $ENV{Y} -c $ENV{Z} ;   ( -a , -b, -c  are also the
arguments to call the script)


( the $ENV{x}=C:\xyz\abc,$ENV{Y}=abc,$ENV{Z}=5).


I understand we have to configure std options,but no idea how to do this.

Can somebody help me on this please?


Thanks in advance,
perl guy


Re: hwo to configure the Getopt:::STD options for command line arguments.

2006-10-16 Thread W.P.Nijhof

perl pra wrote:

hi All,


I have to call some perl scripts with command line arguements from another
perl script.

(some thing like this)

perl -s  -a  $ENV{X}  -b $ENV{Y} -c $ENV{Z} ;   ( -a , -b, -c  are also the
arguments to call the script)


( the $ENV{x}=C:\xyz\abc,$ENV{Y}=abc,$ENV{Z}=5).




Try this

use Getopt::Std;
use strict;

our ($opt_a, $opt_b, $opt_c);

getopts( 'a:b:c:' );

print join \n, ($opt_a, $opt_b, $opt_c);

HtH
WayPay


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




error when install GetOpt::Tabular

2006-06-28 Thread Sheng Bao

hi guys,
  I encountered a problem when install GetOpt::Tabular.
  At the first step, I stopped. Here is the error output.

  [EMAIL PROTECTED] Getopt-Tabular-0.3]# perl ./Makefile.PL
  Config.pm did not return a true value at
/usr/lib/perl5/5.8.6/ExtUtils/MakeMaker.pm line 9.
  BEGIN failed--compilation aborted at
/usr/lib/perl5/5.8.6/ExtUtils/MakeMaker.pm line 9.
  Compilation failed in require at ./Makefile.PL line 1.
  BEGIN failed--compilation aborted at ./Makefile.PL line 1.

And here is the Perl version information.

[EMAIL PROTECTED] Getopt-Tabular-0.3]# perl -version

This is perl, v5.8.6 built for i386-linux-thread-multi


Can anyone help me? Thanks.

Cheers,
Sheng

--
EE is no more about circuits than CS is about computers.

Home Page: http://grandlab.cer.net/~bao
Blog: http://blog.360.yahoo.com/forrestbao
http://spaces.msn.com/forrestbao
MSN: [EMAIL PROTECTED] (IM only)
Gmail: [EMAIL PROTECTED] (Email also)
Yahoo! ID: [EMAIL PROTECTED] (Email also)
AIM: forrestbao
Skype: forrestbao


Re: error when install GetOpt::Tabular

2006-06-28 Thread Rob Dixon

Sheng Bao wrote:


hi guys,
  I encountered a problem when install GetOpt::Tabular.
  At the first step, I stopped. Here is the error output.

  [EMAIL PROTECTED] Getopt-Tabular-0.3]# perl ./Makefile.PL
  Config.pm did not return a true value at
/usr/lib/perl5/5.8.6/ExtUtils/MakeMaker.pm line 9.
  BEGIN failed--compilation aborted at
/usr/lib/perl5/5.8.6/ExtUtils/MakeMaker.pm line 9.
  Compilation failed in require at ./Makefile.PL line 1.
  BEGIN failed--compilation aborted at ./Makefile.PL line 1.

And here is the Perl version information.

[EMAIL PROTECTED] Getopt-Tabular-0.3]# perl -version

This is perl, v5.8.6 built for i386-linux-thread-multi

Can anyone help me? Thanks.


Hi Sheng

Your Config.pm file has been corrupted somehow. It is built when Perl
is installed and should have a 'true' value as the last executable
statement in the file. Take a look and see if it is obvious what has gone
wrong. If you can't see how to fix it it is probably best to reinstall
Perl.

HTH,

Rob

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Getopt::Long

2005-11-08 Thread Shawn Corey

Chris Knipe wrote:

So, this is more of a block question I think, but how I can get the above
example to show the help screen FIRST, and THEN complain about the missing
value for -s 


Why?

Here's an example of how to do it:

#!/usr/bin/perl

use strict;
use warnings;

use File::Basename;
use File::Copy 'copy';

my $TmpDir = '/tmp';  # Change to 'C:\TEMP' for MS DOS

my $Self = basename( $0 );
my $SaveOutFile = $TmpDir/$Self.$$.out;
my $SaveErrFile = $TmpDir/$Self.$$.err;

open SAVE_OUT, STDOUT;
open SAVE_ERR, STDERR;

my $umask = umask 0600;
open STDERR,  $SaveErrFile;
open STDOUT,  $SaveOutFile;
umask $umask;

my $string = '';
unless( GetOptions(
  'help'  = \ShowHelp,
  'b=s'   = \$string,
)){
  open STDOUT, SAVE_OUT;
  open STDERR, SAVE_ERR;
  copy( $SaveErrFile, STDERR );
  copy( $SaveOutFile, STDOUT );
  ShowHelp;
}

if( $string ){
  open STDOUT, SAVE_OUT;
  open STDERR, SAVE_ERR;
  copy( $SaveErrFile, STDERR );
  copy( $SaveOutFile, STDOUT );

  # Place string munging here

}else{
  open STDOUT, SAVE_OUT;
  open STDERR, SAVE_ERR;
  ShowHelp;
  copy( $SaveErrFile, STDERR );
  copy( $SaveOutFile, STDOUT );
}

__END__


--

Just my 0.0002 million dollars worth,
   --- Shawn

Probability is now one. Any problems that are left are your own.
   SS Heart of Gold, _The Hitchhiker's Guide to the Galaxy_

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Getopt::Long

2005-11-08 Thread Bob Showalter

Chris Knipe wrote:

Hi all,
 
Just a quick question and a couple of lines of really simple code 
 
use Getopt::Long;
 
...
 
GetOptions ('h'   = \$h,

'b=s' = \$s );

Sub ShowHelp() {


That should be

  sub ShowHelp {

Perl isn't VB :)


  print this is help
}

Sub DoSomethingWithString() {
...
}

If ($s) {
  DoSomethingWithString();
} else {
  ShowHelp();
}
 
Right.  Now, whilst the above is not perhaps 100% correct, it goes about a

generality of Getopt::Long.

If I now run the application,
./blah.pl -h   - I get the help screen
./blah.pl -s   - I get a error, complaining that -s requires a value, and
THEN the help screen.
./blah.pl -s s - Everything is fine.

So, this is more of a block question I think, but how I can get the above
example to show the help screen FIRST, and THEN complain about the missing
value for -s 


Well, this is a little tricky, because the complaint is issued by the 
GetOptions() call. I would usually do something like:


   # just show the complaint
   GetOptions(...blah...) or exit 1;

or

   # show the complaint, then the help
   GetOptions(...blah...) or ShowHelp(), exit 1;

In order to show the help before the complaint, you need to capture 
the complaint with $SIG{__WARN__} something like this:


   my $msg = '';
   do {
   local $SIG{__WARN__} = sub { $msg .= shift };
   GetOptions('h'   = \$h, 'b=s' = \$s );
   } or ShowHelp(), die $msg;

I would suggest sending the help text to STDERR, or unbuffering STDOUT 
so that you are sure to get the help text shown before the complaint.


Also, you might look at Pod::Usage for an approach to handling the help 
text.


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Getopt::Long

2005-11-07 Thread Chris Knipe
Hi all,
 
Just a quick question and a couple of lines of really simple code 
 
use Getopt::Long;
 
...
 
GetOptions ('h'   = \$h,
'b=s' = \$s );

Sub ShowHelp() {
  print this is help
}

Sub DoSomethingWithString() {
...
}

If ($s) {
  DoSomethingWithString();
} else {
  ShowHelp();
}
 
Right.  Now, whilst the above is not perhaps 100% correct, it goes about a
generality of Getopt::Long.

If I now run the application,
./blah.pl -h   - I get the help screen
./blah.pl -s   - I get a error, complaining that -s requires a value, and
THEN the help screen.
./blah.pl -s s - Everything is fine.

So, this is more of a block question I think, but how I can get the above
example to show the help screen FIRST, and THEN complain about the missing
value for -s 

Thanks,
 
 
--
Regards,
Chris.
 


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




RE: Getopt::Long

2005-11-07 Thread Timothy Johnson

An excerpt from the documentation:


  my $tag = '';   # option variable with default value
  GetOptions ('tag=s' = \$tag);

  In the option specification, the option name is followed by an equals
  sign = and the letter s. The equals sign indicates that this
option
  requires a value. The letter s indicates that this value is an
  arbitrary string. Other possible value types are i for integer
  values...







-Original Message-
From: Chris Knipe [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 07, 2005 7:38 PM
To: beginners@perl.org
Subject: Getopt::Long

Hi all,
 
Just a quick question and a couple of lines of really simple code 
 
use Getopt::Long;
 
...
 
GetOptions ('h'   = \$h,
'b=s' = \$s );

Sub ShowHelp() {
  print this is help
}

Sub DoSomethingWithString() {
...
}

If ($s) {
  DoSomethingWithString();
} else {
  ShowHelp();
}
 
Right.  Now, whilst the above is not perhaps 100% correct, it goes about
a
generality of Getopt::Long.

If I now run the application,
./blah.pl -h   - I get the help screen
./blah.pl -s   - I get a error, complaining that -s requires a value,
and
THEN the help screen.
./blah.pl -s s - Everything is fine.

So, this is more of a block question I think, but how I can get the
above
example to show the help screen FIRST, and THEN complain about the
missing
value for -s 

Thanks,
 
 
--
Regards,
Chris.
 


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




getopt long behaviour

2005-09-09 Thread Manish Sapariya

Shouldn't following snippet throw error message when
it is called without any parameter?

I can't see any error messsage, why?


#  /tmp/test.pl
Executed successfully
#
--
#!/usr/bin/perl

use Getopt::Long;
GetOptions(verbose  = \$verbose,
  debug= \$debug,
  output=s = \$output) || print No inputs specified\n;

print Executed successfully\n;
---

Thanks,
Manish

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: getopt long behaviour

2005-09-09 Thread Chris Devers
On Fri, 9 Sep 2005, Manish Sapariya wrote:

 Shouldn't following snippet throw error message when
 it is called without any parameter?
 
 I can't see any error messsage, why?

Because this didn't have an error. 

If you want it to quit, force it to quit. 
 
#!/usr/bin/perl
 
use Getopt::Long;
GetOptions(verbose  = \$verbose,
   debug= \$debug,
   output=s = \$output) || print No inputs specified\n;

die No output specified unless defined $output;

print Executed successfully\n;
 


-- 
Chris Devers

u+ûQ!Vév—Ø
-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response


Re: getopt long behaviour

2005-09-09 Thread Manish Sapariya

Oh, my understanding is that when I specify

output=s
its a mandatory parameter and if not specified on command line,
GetOptions should return error.

Am i missing something?
Thanks,
Manish


On 09/09/2005 05:56 PM, Chris Devers wrote:

On Fri, 9 Sep 2005, Manish Sapariya wrote:



Shouldn't following snippet throw error message when
it is called without any parameter?

I can't see any error messsage, why?



Because this didn't have an error. 

If you want it to quit, force it to quit. 
 
#!/usr/bin/perl
 
use Getopt::Long;

GetOptions(verbose  = \$verbose,
   debug= \$debug,
   output=s = \$output) || print No inputs specified\n;

die No output specified unless defined $output;

print Executed successfully\n;
 





--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: getopt long behaviour

2005-09-09 Thread Manish Sapariya

Oh, my understanding is that when I specify

output=s
its a mandatory parameter and if not specified on command line,
GetOptions should return error.

Am i missing something?
Thanks,
Manish



On 09/09/2005 05:56 PM, Chris Devers wrote:


On Fri, 9 Sep 2005, Manish Sapariya wrote:

 


Shouldn't following snippet throw error message when
it is called without any parameter?

I can't see any error messsage, why?
   



Because this didn't have an error. 

If you want it to quit, force it to quit. 


   #!/usr/bin/perl

   use Getopt::Long;
   GetOptions(verbose  = \$verbose,
  debug= \$debug,
  output=s = \$output) || print No inputs specified\n;

   die No output specified unless defined $output;

   print Executed successfully\n;



 




--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Getopt::Mixed

2005-04-23 Thread Carlos Mantero
Hi everybody! I'm very newbie programmer of Perl and I can't make a
little program with a small number of arguments with this Perl module,
Getopt::Mixed. I like that somebody will can make a simple program
exemple with some argument. Thanks for all.

Regards,
Carlos Mantero.


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: GetOpt::Long

2005-04-22 Thread John Doe
Hi Wim

 Hi Bob,

 You gave me the following answer earlier:

sub foo {

   local @ARGV = @_;
   GetOptions(...blah...);

   ...
}

 If I run it as a seperate script, commenting out the (local @ARGV = @_;)
 line, then it works.  But it does not work when called as a subroutine from
 within the main script. 

Can you be more specific about does not work and called ... from within the 
main script?

Your code below is not a functional example, so I made some changes
(especially inserting use strict and use warnings which alway gives good 
hints :-), 
and it works - but maybe in the sense you mentioned that it works for you too:

=== begin script (test3.pl) ===
use strict; use warnings;
use Getopt::Long;

sub notify_email {
  local @ARGV = @_;

  my (@recipients, @subject, @body);
  my %conf=(smtp='whatever', smtpsender='something');

  $ENV{NTsendmail}  = $conf{'smtp'};
  my $sender = $conf{'smtpsender'};

  GetOptions (r=s  = [EMAIL PROTECTED],
  s=s  = [EMAIL PROTECTED],
  b=s  = [EMAIL PROTECTED]);
  my $subject= join( , @subject);
  my $body   = join( , @body);

  foreach my $recipient (@recipients) {
print $sender, $recipient, $subject, $body\n;
#$mail = new NTsendmail;
#$mail-send($sender, $recipient, $subject, $body);
  }
}

notify_email (@ARGV);
=== end script ===

This prints:

something, , sss, 


 I have also tried (my @ARGV = @_;). 
 Any idea why?

 Here is my code now:
 =
 # Notify recipients via SMTP (email)
 # Usage: notify_email -r [EMAIL PROTECTED] -r [EMAIL PROTECTED] -s Subject 
 line -b
 Message body
 sub notify_email {
   local @ARGV = @_;   # Get the sub's params into the master param array
 for GetOpt::Long
   $ENV{NTsendmail}  = $conf{'smtp'};
   $sender = $conf{'smtpsender'};

   GetOptions (r=s  = [EMAIL PROTECTED],   # -r [EMAIL PROTECTED] -r 
 [EMAIL PROTECTED]
 -r [EMAIL PROTECTED]
   s=s  = [EMAIL PROTECTED],  # -s This is the subject
 line...
   b=s  = [EMAIL PROTECTED]);# -b This is the 
 message
 body...

   $subject= join( , @subject);
   $body   = join( , @body);

   foreach $recipient (@recipients) {
 print $sender, $recipient, $subject, $body\n;
 $mail = new NTsendmail;
 $mail-send($sender, $recipient, $subject, $body);
   }
 }
 =

 ___
___

 Standard Bank Disclaimer and Confidentiality Note
[...]


hth, joe

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




RE: GetOpt::Long

2005-04-21 Thread Olivier, Wim W
Hi Bob,

(Offer Kaye, thanks for the reply as well!)

I used the method below (local @ARGV = @_;) to get the values of @_ into
@ARGV for the use of Getopt::Long.  It appears to be working fine like that.
I now have another problem with, it appears, syntax. The IF statement is
part of a block in the switch statement, but there is nothing wrong with the
switch statement itself, as there are many identical if statements there. If
I comment out this if statement, I don't get the error anymore.  An clues as
to the correct syntax???

I run the subroutine as follows:

if ($conf{'pnl_check_for_analytics_email'} =~ 'ON')
   { notify_email -r [EMAIL PROTECTED] -r
[EMAIL PROTECTED] -s Subject line -b Message body };


But I get the following error when it executes:

Bad switch statement (problem in the code block?)



Please see the code below:


==
# Notify recipients via SMTP (email)
# Usage: notify_email -r [EMAIL PROTECTED] -r [EMAIL PROTECTED] -s Subject 
line -b
Message body
sub notify_email {
  local @ARGV = @_;   # Get the sub's params into the master param array for
GetOpt::Long
  $ENV{NTsendmail}  = $conf{'smtp'};
  $sender = $conf{'smtpsender'};

  my @recipients;
  my @subject;
  my $body;
  GetOptions (r=s  = [EMAIL PROTECTED],   # -r [EMAIL PROTECTED] -r 
[EMAIL PROTECTED]
-r [EMAIL PROTECTED]
  s=s  = $subject,  # -s This is the subject
line...
  b=s  = $body);# -b This is the message
body...
  [EMAIL PROTECTED] = split(/,/,join(',',@recipients));
  #$subject= join( , @subject);
  #$body   = join( , @body);

  foreach $recipient (@recipients) {
print $sender, $recipient, $subject, $body\n;
$mail = new NTsendmail;
$mail-send($sender, $recipient, $subject, $body);
  }

}

==

-Original Message-
From: Bob Showalter [mailto:[EMAIL PROTECTED]
Sent: 20 April 2005 02:31 PM
To: Olivier, Wim W; Perl Beginners (E-mail)
Subject: RE: GetOpt::Long


Olivier, Wim W wrote:
 Hi all,
 
 Is it possible to use GetOpt::Long (or something similar) in a
 subroutine 
 using @_ instead of in the standard way (using @ARGV)?


This should work:

   sub foo {

  local @ARGV = @_;
  GetOptions(...blah...);

  ...
   }

__

Standard Bank Disclaimer and Confidentiality Note

This e-mail, its attachments and any rights attaching hereto are, unless the 
context clearly indicates otherwise, the property of Standard Bank Group 
Limited and/or its subsidiaries (the Group). It is confidential, private and 
intended for the addressee only. 

Should you not be the addressee and receive this e-mail by mistake, kindly 
notify the sender, and delete this e-mail, immediately and do not disclose or 
use same in any manner whatsoever. 

Views and opinions expressed in this e-mail are those of the sender unless 
clearly stated as those of the Group. The Group accepts no liability whatsoever 
for any loss or damages whatsoever and howsoever incurred, or suffered, 
resulting, or arising, from the use of this email or its attachments.

The Group does not warrant the integrity of this e-mail nor that it is free of 
errors, viruses, interception or interference. 

Licensed divisions of the Standard Bank Group are authorised financial services 
providers in terms of the Financial Advisory and Intermediary Services Act, No 
37 of 2002 (FAIS).

For information about the Standard Bank Group Limited visit our website 
http://www.standardbank.co.za
___

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




RE: GetOpt::Long

2005-04-21 Thread Bob Showalter
Olivier, Wim W wrote:
 Hi Bob,

Hi. Don't top-post please.

 If 
 I comment out this if statement, I don't get the error anymore.  An
 clues as 
 to the correct syntax???
 
 I run the subroutine as follows:
 
 if ($conf{'pnl_check_for_analytics_email'} =~ 'ON')
{ notify_email -r [EMAIL PROTECTED] -r
 [EMAIL PROTECTED] -s Subject line -b Message body };

You need to pass your arguments as a proper list, with commas and quotes:

notify_email('-r', '[EMAIL PROTECTED]',
'-r', '[EMAIL PROTECTED]', 
'-s', 'Subject Line',
'-b', 'Message Body');

You can omit the parens if notify_email has been declared above this code,
but I dont' recommend it.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




RE: GetOpt::Long

2005-04-21 Thread Olivier, Wim W
Hi Bob,

You gave me the following answer earlier:

   sub foo {

  local @ARGV = @_;
  GetOptions(...blah...);

  ...
   }

If I run it as a seperate script, commenting out the (local @ARGV = @_;)
line, then it works.  But it does not work when called as a subroutine from
within the main script. I have also tried (my @ARGV = @_;).
Any idea why?

Here is my code now:
=
# Notify recipients via SMTP (email)
# Usage: notify_email -r [EMAIL PROTECTED] -r [EMAIL PROTECTED] -s Subject 
line -b
Message body
sub notify_email {
  local @ARGV = @_;   # Get the sub's params into the master param array for
GetOpt::Long
  $ENV{NTsendmail}  = $conf{'smtp'};
  $sender = $conf{'smtpsender'};

  GetOptions (r=s  = [EMAIL PROTECTED],   # -r [EMAIL PROTECTED] -r 
[EMAIL PROTECTED]
-r [EMAIL PROTECTED]
  s=s  = [EMAIL PROTECTED],  # -s This is the subject
line...
  b=s  = [EMAIL PROTECTED]);# -b This is the message
body...

  $subject= join( , @subject);
  $body   = join( , @body);

  foreach $recipient (@recipients) {
print $sender, $recipient, $subject, $body\n;
$mail = new NTsendmail;
$mail-send($sender, $recipient, $subject, $body);
  }
}
=

__

Standard Bank Disclaimer and Confidentiality Note

This e-mail, its attachments and any rights attaching hereto are, unless the 
context clearly indicates otherwise, the property of Standard Bank Group 
Limited and/or its subsidiaries (the Group). It is confidential, private and 
intended for the addressee only. 

Should you not be the addressee and receive this e-mail by mistake, kindly 
notify the sender, and delete this e-mail, immediately and do not disclose or 
use same in any manner whatsoever. 

Views and opinions expressed in this e-mail are those of the sender unless 
clearly stated as those of the Group. The Group accepts no liability whatsoever 
for any loss or damages whatsoever and howsoever incurred, or suffered, 
resulting, or arising, from the use of this email or its attachments.

The Group does not warrant the integrity of this e-mail nor that it is free of 
errors, viruses, interception or interference. 

Licensed divisions of the Standard Bank Group are authorised financial services 
providers in terms of the Financial Advisory and Intermediary Services Act, No 
37 of 2002 (FAIS).

For information about the Standard Bank Group Limited visit our website 
http://www.standardbank.co.za
___

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




GetOpt::Long

2005-04-20 Thread Olivier, Wim W
Hi all,

Is it possible to use GetOpt::Long (or something similar) in a subroutine
using @_ instead of in the standard way (using @ARGV)?
I want to have the following scenario, but use GetOpt in a subrouting within
the main script and pass options (and values) to the subroutine.
The values ($recipient, $subject, $body) must be configurable and they must
be able to take multiple values, i.e. multiple recipients for a message.


# Notify recipients via SMTP (email)
sub notify_email {
  $ENV{NTsendmail}  = $smtp;
  $sender = [EMAIL PROTECTED];
  $recipient  = [EMAIL PROTECTED];
  $subject= ALERT;
  $body   = join  , @_;
  $mail   = new NTsendmail;
  $mail-send($sender, $recipient, $subject, $body);
}


All help appreciated!  Thanks in advance.


Kind Regards,

Wim Olivier

__

Standard Bank Disclaimer and Confidentiality Note

This e-mail, its attachments and any rights attaching hereto are, unless the 
context clearly indicates otherwise, the property of Standard Bank Group 
Limited and/or its subsidiaries (the Group). It is confidential, private and 
intended for the addressee only. 

Should you not be the addressee and receive this e-mail by mistake, kindly 
notify the sender, and delete this e-mail, immediately and do not disclose or 
use same in any manner whatsoever. 

Views and opinions expressed in this e-mail are those of the sender unless 
clearly stated as those of the Group. The Group accepts no liability whatsoever 
for any loss or damages whatsoever and howsoever incurred, or suffered, 
resulting, or arising, from the use of this email or its attachments.

The Group does not warrant the integrity of this e-mail nor that it is free of 
errors, viruses, interception or interference. 

Licensed divisions of the Standard Bank Group are authorised financial services 
providers in terms of the Financial Advisory and Intermediary Services Act, No 
37 of 2002 (FAIS).

For information about the Standard Bank Group Limited visit our website 
http://www.standardbank.co.za
___

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




RE: GetOpt::Long

2005-04-20 Thread Tim Johnson


How about something like this?  It doesn't make it like GetOpt::Long,
but it does handle what you want.  Or you could just require that people
pass an array to your subroutine and save yourself a little work.  If
there is only one recipient, then it's a one-element array.

#

my $recipients = '[EMAIL PROTECTED]';
notify_email('[EMAIL PROTECTED]',$recipients,test,this is my
body);
#my @recipients = qw([EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]);
#notify_email('[EMAIL PROTECTED]',[EMAIL PROTECTED],test,this is the
body);

sub notify_email{
   my ($sender,$rcpt,$subj,$body) = @_;
   my $recipient;
   if(ref($rcpt)){
   if(ref($rcpt) eq 'ARRAY'){
   $recipient = join(',',@{$rcpt});
   }elsif(ref($rcpt) eq 'SCALAR'){
   $recipient = ${$rcpt};
   }else{
   die Invalid recipient parameter!\n;
   }
   }else{
   $recipient = $rcpt;
   }
   print $recipient.\n;
}

#

-Original Message-
From: Olivier, Wim W [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 20, 2005 12:53 AM
To: Perl Beginners (E-mail)
Subject: GetOpt::Long

Hi all,

Is it possible to use GetOpt::Long (or something similar) in a
subroutine
using @_ instead of in the standard way (using @ARGV)?
I want to have the following scenario, but use GetOpt in a subrouting
within
the main script and pass options (and values) to the subroutine.
The values ($recipient, $subject, $body) must be configurable and they
must
be able to take multiple values, i.e. multiple recipients for a message.


# Notify recipients via SMTP (email)
sub notify_email {
  $ENV{NTsendmail}  = $smtp;
  $sender = [EMAIL PROTECTED];
  $recipient  = [EMAIL PROTECTED];
  $subject= ALERT;
  $body   = join  , @_;
  $mail   = new NTsendmail;
  $mail-send($sender, $recipient, $subject, $body);
}



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




RE: GetOpt::Long

2005-04-20 Thread Bob Showalter
Olivier, Wim W wrote:
 Hi all,
 
 Is it possible to use GetOpt::Long (or something similar) in a
 subroutine 
 using @_ instead of in the standard way (using @ARGV)?


This should work:

   sub foo {

  local @ARGV = @_;
  GetOptions(...blah...);

  ...
   }

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: GetOpt::Long

2005-04-20 Thread Offer Kaye
On 4/20/05, Olivier, Wim W wrote:
 Hi all,
 
 Is it possible to use GetOpt::Long (or something similar) in a subroutine

Getargs::Long - 
http://search.cpan.org/dist/Getargs-Long/

HTH,
-- 
Offer Kaye

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




need help for Getopt::Long;

2005-03-25 Thread Shiping Wang
Hi, I have problem to match array defined in Getopt::Long and transfer to 
new file:
If I do:
try.pl --InputData sample.txt --Trait=_BMI --covars=age, _DBP, _SBP 
--Race=Others
with this file:
GFAMID  GDADID  GMOMID  ID  SEX 
HYT3  _SBP  _DBP  _BMI  RACE  AGE	 _HTMED  antiht

How can I get it to new file like this:
A   HYT3
C   _SBP
C   _DBP
T   _BMI
S   RACE
C   AGE
S   _HTMED
S   antiht
Thanks!!!
SW
###
#!/usr/local/bin/perl
# try.pl
use warnings;
use strict;
use Getopt::Long;
		my $inputData =' ';
		my $trait= ' ';
		my $race;
		my @covars;
		my $result = GetOptions(InputData=s = \$inputData,
Trait=s = \$trait,
Race=s = \$race,
Covars=s = [EMAIL PROTECTED]
);
		my @covarlist = split(/[\s|,]/, @covars);		
		if(!$inputData){
			exit();
		}
	#die you must specify all parameters\n\t--Trait --Race --Covars\n 
unless(define $trait || define $race || define @covars);
my $oriname = (split/\./, $inputData)[0];
my $outname;
if ($race){
	$outname = $oriname\_$race;
} else{
	$outname = $oriname;
}
		

open (outDat, $outname.dat) or die $!;
open (inPed, $inputData) or die $!;
my $header = inPed;
chomp $header;
my @headline = split/\t/, $header;
my @ped_n_trait = @headline[0, 3, 1, 2, 4..12];
my %vartype;
foreach my $i (@ped_n_trait[5..12]){
if ($i eq 'HYT3'){
$vartype{$i} = 'A';
}elsif ($i eq $trait){
$vartype{$i} = 'T';
}else{
$vartype{$i} = 'S';
for(@covarlist){
if($_ eq $i){
$vartype{$_} = 'C';
}
}

}
}
for (@ped_n_trait[5..12]){
print outDat $vartype{$_}\t$_\n;
}
close outDat;
close inPed;

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response



Re: need help for Getopt::Long; --resolved

2005-03-25 Thread Shiping Wang
At 10:46 AM 3/25/2005 -0600, Shiping Wang wrote:
Hi, I have problem to match array defined in Getopt::Long and transfer to 
new file:
If I do:
try.pl --InputData sample.txt --Trait=_BMI --covars=age, _DBP, _SBP 
--Race=Others
with this file:
GFAMID  GDADID  GMOMID  ID  SEX 
HYT3  _SBP  _DBP  _BMI  RACE  AGE   _HTMED  antiht

How can I get it to new file like this:
A   HYT3
C   _SBP
C   _DBP
T   _BMI
S   RACE
C   AGE
S   _HTMED
S   antiht
Thanks!!!
SW
###
#!/usr/local/bin/perl
# try.pl
use warnings;
use strict;
use Getopt::Long;
my $inputData =' ';
my $trait= ' ';
my $race;
my @covars;
my $result = GetOptions(InputData=s = \$inputData,
Trait=s 
= \$trait,
Race=s 
= \$race,

Covars=s = [EMAIL PROTECTED]
);
my @covarlist = split(/,/, 
@covars);
if(!$inputData){
exit();
}
#die you must specify all parameters\n\t--Trait --Race 
--Covars\n unless(define $trait || define $race || define @covars);
my $oriname = (split/\./, $inputData)[0];
my $outname;
if ($race){
$outname = $oriname\_$race;
} else{
$outname = $oriname;
}

open (outDat, $outname.dat) or die $!;
open (inPed, $inputData) or die $!;
my $header = inPed;
chomp $header;
my @headline = split/\t/, $header;
my @ped_n_trait = @headline[0, 3, 1, 2, 4..12];
my %vartype;
### not working
foreach my $i (@ped_n_trait[5..12]){
if ($i eq 'HYT3'){
$vartype{$i} = 'A';
}elsif ($i eq $trait){
$vartype{$i} = 'T';
}else{
$vartype{$i} = 'S';
for(@covarlist){
if($_ eq $i){
$vartype{$_} = 'C';
}
}
}
}
### working, maybe better way to it ###
foreach my $i (@ped_n_trait[5..12]){
if ($i eq 'HYT3'){
$vartype{$i} = 'A';
}elsif ($i eq $trait){
$vartype{$i} = 'T';
}else{
for(@covarlist){
  if($_ eq $i){
$vartype{$i} = 'C';
}
$vartype{$i} = 'S' if (!$vartype{$i});
}
}
}
for (@ped_n_trait[5..12]){
print outDat $vartype{$_}\t$_\n;
}
close outDat;
close inPed;

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response



Getopt::Long , handles the number zero differently..

2004-12-21 Thread Mike Donnelly


 Using the example code below, I find that I can 
  use getopt handily to pass all sorts of 
  variables to my script, as long as a 
  value passed is not a 0 (zero) 
 
 How to I use getopt::long and be able to 
  pass the number zero as a value? 
  Code, and  behavior follows 
   
   Thanks! Mike D
 .
 MYTEST
 #!/usr/local/bin/perl
 use Getopt::Long;
 GetOptions(o=\$oflag,
 string=s=\$stringmandatory,
 int=i= \$mandatoryinteger,
 print oflag $oflag\n if $oflag;
 print stringmandatory $stringmandatory\n if
 $stringmandatory;
 print mandatoryinteger $mandatoryinteger\n if
 $mandatoryinteger;
 
 print Unprocessed by Getopt::Long\n if $ARGV[0];
 foreach (@ARGV) {
   print $_\n;
 }
 

 # ./MYTEST --string=abc
 stringmandatory abc
 # ./MYTEST --string=1
 stringmandatory 1
 # ./MYTEST --string=0
 # ./MYTEST --int=0
 # ./MYTEST --int=1
 mandatoryinteger 1
 
 




__ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Getopt::Long , handles the number zero differently..

2004-12-21 Thread mgoland


- Original Message -
From: Mike Donnelly [EMAIL PROTECTED]
Date: Tuesday, December 21, 2004 10:58 am
Subject: Getopt::Long , handles the number zero differently..

Hello
 
 
 Using the example code below, I find that I can 

Please paste working code
  use getopt handily to pass all sorts of 
  variables to my script, as long as a 
  value passed is not a 0 (zero) 

are you sure ??
 
 How to I use getopt::long and be able to 
  pass the number zero as a value? 
exactly as you coded below. The problem is not in your getopt code, but in your 
print statment. The OP if $foo, will return false on integer value of 0. 

  Code, and  behavior follows 
   
   Thanks! Mike D
 .
 MYTEST
 #!/usr/local/bin/perl
 use Getopt::Long;
 GetOptions(o=\$oflag,
 string=s=\$stringmandatory,
 int=i= \$mandatoryinteger,
 print oflag $oflag\n if $oflag;
 print stringmandatory $stringmandatory\n if
 $stringmandatory;
 print mandatoryinteger $mandatoryinteger\n if
 $mandatoryinteger;
# try this
  print mandatoryinteger $mandatoryinteger\n if $mandatoryinteger = 0;
 
 print Unprocessed by Getopt::Long\n if $ARGV[0];
 foreach (@ARGV) {
   print $_\n;
 }
 
 
 # ./MYTEST --string=abc
 stringmandatory abc
 # ./MYTEST --string=1
 stringmandatory 1
 # ./MYTEST --string=0
 # ./MYTEST --int=0
 # ./MYTEST --int=1
 mandatoryinteger 1

HTH,
Mark G
 
 
 
 
 
   
 __ 
 Do you Yahoo!? 
 The all-new My Yahoo! - Get yours free! 
 http://my.yahoo.com 
 
 
 
 -- 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 http://learn.perl.org/ http://learn.perl.org/first-response
 
 
 


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Getopt::Long , handles the number zero differently..

2004-12-21 Thread Mike Donnelly

--- [EMAIL PROTECTED] wrote:
 
 
 - Original Message -
 From: Mike Donnelly [EMAIL PROTECTED]
 Date: Tuesday, December 21, 2004 10:58 am
 Subject: Getopt::Long , handles the number zero
 differently..
 
 Hello
  
  
  Using the example code below, I find that I can 
 
 Please paste working code

Sorry Bout' that .. chopped a line 

   use getopt handily to pass all sorts of 
   variables to my script, as long as a 
   value passed is not a 0 (zero) 
 
 are you sure ??

Well, I WAS sure.. 

  
  How to I use getopt::long and be able to 
   pass the number zero as a value? 

 exactly as you coded below. The problem is not in
 your getopt code, but in your print statment. The OP
 if $foo, will return false on integer value of 0. 

You are correct and I thank you for the help.
 
 
   Code, and  behavior follows 

Thanks! Mike D
  .
  MYTEST
  #!/usr/local/bin/perl
  use Getopt::Long;
  GetOptions(o=\$oflag,
  string=s=\$stringmandatory,
  int=i= \$mandatoryinteger,
  print oflag $oflag\n if $oflag;
  print stringmandatory $stringmandatory\n if
  $stringmandatory;
  print mandatoryinteger $mandatoryinteger\n if
  $mandatoryinteger;
 # try this
   print mandatoryinteger $mandatoryinteger\n if
 $mandatoryinteger = 0;
  
  print Unprocessed by Getopt::Long\n if $ARGV[0];
  foreach (@ARGV) {
print $_\n;
  }
  
  
  # ./MYTEST --string=abc
  stringmandatory abc
  # ./MYTEST --string=1
  stringmandatory 1
  # ./MYTEST --string=0
  # ./MYTEST --int=0
  # ./MYTEST --int=1
  mandatoryinteger 1
 
 HTH,
 Mark G
  
  
  
  
  
  
  __ 
  Do you Yahoo!? 
  The all-new My Yahoo! - Get yours free! 
  http://my.yahoo.com 
  
  
  
  -- 
  To unsubscribe, e-mail:
 [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
  http://learn.perl.org/
 http://learn.perl.org/first-response
  
  
  
 
 




__ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Getopt::Long , handles the number zero differently..

2004-12-21 Thread Mike Donnelly

Using the example code below, I find that I can 
 use getopt handily to pass all sorts of 
 variables to my script, as long as a 
 value passed is not a 0 (zero) 

How to I use getopt::long and be able to 
 pass the number zero as a value? 
 Code, and  behavior follows 
  
  Thanks! Mike D
.
MYTEST
#!/usr/local/bin/perl
use Getopt::Long;
GetOptions(o=\$oflag,
string=s=\$stringmandatory,
int=i= \$mandatoryinteger,
print oflag $oflag\n if $oflag;
print stringmandatory $stringmandatory\n if
$stringmandatory;
print mandatoryinteger $mandatoryinteger\n if
$mandatoryinteger;

print Unprocessed by Getopt::Long\n if $ARGV[0];
foreach (@ARGV) {
  print $_\n;
}

# ./MYTEST -stringmandatory=1
Unknown option: stringmandatory
# ./MYTEST --stringmandatory=1
Unknown option: stringmandatory
# ./MYTEST --string
Option string requires an argument
# ./MYTEST --string
Option string requires an argument
# ./MYTEST --string=abc
stringmandatory abc
# ./MYTEST --string=1
stringmandatory 1
# ./MYTEST --string=0
# ./MYTEST --int=0
# ./MYTEST --int=1
mandatoryinteger 1


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Getopt::Long , handles the number zero differently..

2004-12-21 Thread John W. Krahn
Mike Donnelly wrote:
 Using the example code below, I find that I can 
  use getopt handily to pass all sorts of 
  variables to my script, as long as a 
  value passed is not a 0 (zero) 
 
 How to I use getopt::long and be able to 
  pass the number zero as a value? 
  Code, and  behavior follows 
   
 .
 MYTEST
 #!/usr/local/bin/perl
 use Getopt::Long;
 GetOptions(o=\$oflag,
 string=s=\$stringmandatory,
 int=i= \$mandatoryinteger,
 print oflag $oflag\n if $oflag;
 print stringmandatory $stringmandatory\n if
 $stringmandatory;
 print mandatoryinteger $mandatoryinteger\n if
 $mandatoryinteger;
Change the previous three lines to:
 print oflag $oflag\n if defined $oflag;
 print stringmandatory $stringmandatory\n if defined $stringmandatory;
 print mandatoryinteger $mandatoryinteger\n if defined $mandatoryinteger;

 print Unprocessed by Getopt::Long\n if $ARGV[0];
Change that one to:
 print Unprocessed by Getopt::Long\n if @ARGV;
($ARGV[0] could also be 0!)

 foreach (@ARGV) {
   print $_\n;
 }

John
--
use Perl;
program
fulfillment
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response



Re: strict getopt()

2004-10-17 Thread Peter Scott
In article [EMAIL PROTECTED],
 [EMAIL PROTECTED] (Christian Stalp) writes:
What can I do to use getopt() and use strict? 
If I use strict I have to declare all of my variables. And if I do this, perl 
ignores my getopt(s) single-chars. Is this normal? What can I do to solve 
this? 

Learn about references; there is another argument allowed for the
getopts() function.  Try this:

use Getopt::Std;
my %opt;
getopts('abcde', \%opt);

Now run that with some options and inspect the hash %opt after the
getopts() call.

I want to use perl with -w option and the strict pracma. Is this posible?

Not only possible, I consider it mandatory :-)

-- 
Peter Scott
http://www.perldebugged.com/
*** NEW *** http://www.perlmedic.com/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




strict getopt()

2004-10-15 Thread Christian Stalp
Hello together, I have a new problem.

What can I do to use getopt() and use strict? 
If I use strict I have to declare all of my variables. And if I do this, perl 
ignores my getopt(s) single-chars. Is this normal? What can I do to solve 
this? 

I want to use perl with -w option and the strict pracma. Is this posible?

Gruss Christian

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: strict getopt()

2004-10-15 Thread Jeff 'japhy' Pinyan
On Oct 15, Christian Stalp said:

What can I do to use getopt() and use strict?

Declare your variables with our() if you're using Perl 5.6 or better;
otherwise, declare them with 'use vars'.

If I use strict I have to declare all of my variables. And if I do this, perl
ignores my getopt(s) single-chars. Is this normal? What can I do to solve
this?

I want to use perl with -w option and the strict pracma. Is this posible?

If you're using Perl 5.6, don't use -w anymore, use the warnings
pragma.

-- 
Jeff japhy Pinyan %  How can we ever be the sold short or
RPI Acacia Brother #734 %  the cheated, we who for every service
http://japhy.perlmonk.org/  %  have long ago been overpaid?
http://www.perlmonks.org/   %-- Meister Eckhart


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: strict getopt()

2004-10-15 Thread Christian Stalp
 Declare your variables with our() if you're using Perl 5.6 or better;
 otherwise, declare them with 'use vars'.

All right, it works now, thank you very much.

 If you're using Perl 5.6, don't use -w anymore, use the warnings
 pragma.

warnings? How does this works? 
#!/usr/bin/perl warnings
or 
use warnings; ?
I just tested it, and both were accepted. 

Gruss Christian


-- 
Christian Stalp

Institut für Medizinische Biometrie, Epidemiologie und Informatik (IMBEI)
Obere Zahlbacher Straße 69
55131 Mainz
Tel.: 06131/ 17-6852

E-Mail: [EMAIL PROTECTED]
Internet: www.imbei.de

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Opening file($ARGV) with Getopt - failing

2004-09-28 Thread Edward Wijaya
Hi,
Why my code below fail to open and
print the file contents
when I do:
perl mycode.pl -f filename
Regards,
Edward WIJAYA
SINGAPORE
__BEGIN__
use strict;
use warnings;
use Getopt::Std;
use vars qw($f);
getopts('f:');
my  $f = $ARGV[0];
open ( INFILE, '', $f)
or die $0 : failed to open input file $f : $!\n;
close ( INFILE );   
while (  )
{
print $_;
}   
__END__ 
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response



Re: Opening file($ARGV) with Getopt - failing

2004-09-28 Thread Errin Larsen
Hi Edward!


On Tue, 28 Sep 2004 18:51:12 +0800, Edward Wijaya
[EMAIL PROTECTED] wrote:
 Hi,
 Why my code below fail to open and
 print the file contents
 
 when I do:
 
 perl mycode.pl -f filename
 
 Regards,
 Edward WIJAYA
 SINGAPORE
 
 __BEGIN__
 use strict;
 use warnings;

  Good Start!  Those pragmas above are very helpful!

 
 use Getopt::Std;
 use vars qw($f);

  The above is good, but is now obsolete.  The preferred method is to
use 'our' declarations
  Also, the 'getopts()' function creates variables of the form 'opt_*'
where '*' is replaced with
  your option name.  So, for example, you should have declared opt_f here:

our $opt_f;

 getopts('f:');
 
 my  $f = $ARGV[0];
 open ( INFILE, '', $f)
  or die $0 : failed to open input file $f : $!\n;
  
  This is good, I especially like the 'die' statement in case it
fails.  Good Job!  It is relevant
  to note that opening a file to read is default, so the '' was not
necessary.  However, it is
  nice to make it obvious which way you are opening the file (read
only, write, or etc.).  I
  might have written this as follows:

open INFILE, $opt_f or die $0: failed to open input file $opt_f: $!;

 close ( INFILE );
 
  Why are you closing the file you just opened?  Maybe it's because
you don't understand
  the diamond ('') operator.  The diamond operator will read the end
of you command line
  and open each filename it finds there for processing.  It allows you
to write a Perl script
  that acts like any other UNIX process (e.g. cat, grep, etc ... ). 
In your code example,
  it appears as if you are trying NOT to use the diamond operator and
force your user
  to input a single filename with the '-f' option.  If this is the
case, you don't want to close
  your 'INFILE' above until after you've used it!  Like this:

while( INFILE ) {
print;
}

 while (  )
 {
  print $_;

  Inside this block, the '$_' variable is default and will be assigned
the next line from
  the file that 'while' is processing.  Because it is default, it is
not necessary.

 }
 __END__
 
 --
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 http://learn.perl.org/ http://learn.perl.org/first-response
 
 

Edward, I could write this script two ways.  The first is the way I
prefer and it doesn't use 'Getopt::Std' at all:

#!/usr/bin/perl

use warnings;
use strict;

while(  ) {
print;
}

That code above uses the diamond operator correctly.  The diamond
('') operator reads the command line and processes each file name on
the command line after your command!  So, in a command called
'perl_cat.pl' with a command line like:
  # perl_cat.pl foo.txt bar.txt
The diamond operator will first open foo.txt (processed in the while
loop) and print each line, then, open bar.txt and print each of it's
lines!

However, if you are really trying to use the 'Getopt::Std' module, I'd
do it like this:

#!/usr/bin/perl

use warnings;
use strict;

our $opt_f;
getopts( 'f:' );

open INFILE, $opt_f or die $0:  Can't open file $opt_f: $!;

while( INFILE ) {
print;
}

In the above code, unlike yours, I don't 'close' INFILE.  That's
because Perl will close it for me at the end of my code.

I hope this helps!

--Errin

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Opening file($ARGV) with Getopt - failing

2004-09-28 Thread Errin Larsen
Hi again, Edward! 

Just so you know, you should CC the list when you reply!

On Tue, 28 Sep 2004 22:26:55 +0800, Edward Wijaya
[EMAIL PROTECTED] wrote:
 Thanks Errin,
 It works just as you suggested.
 Thanks so much for your thorough
 explanation. Glad that I learnt much from it.
 
 
  Edward, I could write this script two ways.  The first is the way I
  prefer and it doesn't use 'Getopt::Std' at all:
 
 I need to use Getopt, as I will increase
 the number of user given options.
 
 Regards
 Edward WIJAYA
 

I'm glad I could help!!  Just wanted to mention one last thing.  Just
because you have to use Getopt::Std doesn't mean you can't ALSO use
the diamond ('') operator.  Let me demonstrate:

#!/usr/bin/perl

use warnings;
use strict;
use Getopt::Std;

our $opt_p;
getopts( 'p:' );

if( $opt_p ) {
print You used the -p flag.  The value passed was $opt_p\n;
}

while(  ) {
print;
}

The above will print out all the lines of the file found at the END of
your command line (that's the diamond operator at work), but it will
also allow you to specify some other option with a '-p'.  So, if you
have a text file called test.txt:
  Test Data
  More Test Data
  Other Test Data

and you call the above program with this command line:
# test_options.pl test.txt

the output will be as follows: 
  Test Data
  More Test Data
  Other Test Data

if You instead use THIS command line:
# test_options.pl -p foobar test.txt

the output will be as follows:
  You used the -p flag.  The value passed was foobar.
  Test Data
  More Test Data
  Other Test Data

I hope that makes sense.  Don't forget that the diamond operator will
see more than one filename on that command line as well:

# test_options.pl -p foobar test.txt test.txt
  You used the -p flag.  The value passed was foobar.
  Test Data
  More Test Data
  Other Test Data
  Test Data
  More Test Data
  Other Test Data

HTH
--Errin

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Opening file($ARGV) with Getopt - failing

2004-09-28 Thread Chris Devers
On Tue, 28 Sep 2004, Errin Larsen wrote:

 On Tue, 28 Sep 2004 18:51:12 +0800, Edward Wijaya
 [EMAIL PROTECTED] wrote:
 
  use vars qw($f);
 
   The above is good, but is now obsolete. 

That is debatable.

Gather round, and listen to the story of a log handling utility 
written in perl, and a frustrated user. He's not a perl programmer,
he's a Solaris sysadmin. For him, perl is just a tool, just another
language. And the version of perl shipped with his Solaris is
5.005_03.

He is disinclined to build and install a new version of perl just 
to support a single tool. After all, he doesn't have to build
new versions of awk, or new versions of C. Why should perl be any
different?

Trouble is, the author of this tool didn't agree. He had used 
our variables instead of my. Which, of course, don't work in
5.005_03. The user was quite prepared to ditch the tool altogether
and find another because it didn't Just Work. I suggested that he
go through it replacing our with my and lo and behold, it worked.

The moral of this story is that even if you have the latest and 
greatest perl, you shouldn't use the latest and greatest features
unless you absolutely must. Because if you do you will severely
limit who will use your code. our in particular is really only a
convenience, saving a few key strokes at most. So don't use it. 
Ever.

I'll buy a crate of beer for the first person who can show me some 
real-world code which absolutely requires our and can't be 
re-written to use my updateor use vars (cos I meant to say that 
originally as well)/update.

http://www.perlmonks.com/index.pl?node_id=393423

The latest  greatest is only worth using if:

 * it really does offer you something you need
 * it really does offer you something that wasn't available before
 * you really don't have to worry about portability
 * there really aren't downsides to using it

For most people, in most cases, one or more of these won't be true.

It's worth it to be aware of the downsides of using a modern feature 
like `our`, and to be confident that it really does make more sense to 
use it over some older approach. It may be that the new ways really are 
better -- I'm certainly not against progressing the language -- but if a 
new feature breaks otherwise good code, is it worthwhile?


-- 
Chris Devers

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Opening file($ARGV) with Getopt - failing

2004-09-28 Thread Errin Larsen
On Tue, 28 Sep 2004 15:26:08 -0400 (EDT), Chris Devers
[EMAIL PROTECTED] wrote:
 On Tue, 28 Sep 2004, Errin Larsen wrote:
 
  On Tue, 28 Sep 2004 18:51:12 +0800, Edward Wijaya
  [EMAIL PROTECTED] wrote:
 
   use vars qw($f);
 
The above is good, but is now obsolete.
 
 That is debatable.
 
 Gather round, and listen to the story of a log handling utility

SNIP

 It's worth it to be aware of the downsides of using a modern feature
 like `our`, and to be confident that it really does make more sense to
 use it over some older approach. It may be that the new ways really are
 better -- I'm certainly not against progressing the language -- but if a
 new feature breaks otherwise good code, is it worthwhile?
 
 --
 Chris Devers
 

So, what was the justification for changing 'use vars' to 'our'?  Did
the developers just want to shave down the keystrokes?  Was it an
understandability (is that a word?!) issue?  Is there any (deep down,
underneath it all) internal difference between the two?  Is there a
resource to read about this issue?  (I did read the link you supplied,
but it didn't go into WHY this changed.)

The advice I was giving in this thread was based on the following
quote in my 'perldoc Getopt::Std' documentation.  (A quote from that):

 Note that, if your code is running under the recommended
 use strict 'vars' pragma, you will need to declare these
 package variables with our:

 our($opt_foo, $opt_bar);


Later in the docs it DOES say that if you don't want to declare these
as global variables, 'getopts()' will accept a hash reference. 
(Another quote):

 For those of you who don't like additional global variables
 being created, getopt() and getopts() will also accept a
 hash reference as an optional second argument. Hash keys
 will be x (where x is the switch name) with key values the
 value of the argument or 1 if no argument is specified.

Like this:

getopts('oif:', \%opts);  # options as normal. Values in %opts

I have a feeling that that way is the most correct way.  That way
the values being grabbed off the command line options will be scoped
specifically where you want them to be instead of being globals.

comments?

--Errin

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Opening file($ARGV) with Getopt - failing

2004-09-28 Thread John W. Krahn
Edward Wijaya wrote:
 Hi,
Hello,
 Why my code below fail to open and
 print the file contents

 when I do:

 perl mycode.pl -f filename


 __BEGIN__
 use strict;
 use warnings;

 use Getopt::Std;
 use vars qw($f);
 getopts('f:');
getopts( 'f:' ) creates the variable $opt_f and stores the following argument 
'filename' in that variable and *REMOVES* those arguments from @ARGV so that 
@ARGV is now empty.

 my$f = $ARGV[0];
Since @ARGV is now empty, $f is also empty (undef).
 open ( INFILE, '', $f)
 or die $0 : failed to open input file $f : $!\n;
 close ( INFILE );

 while (  )
Since @ARGV is now empty there is nothing for  to open and read from.
 {
 print $_;
 }   __END__
You should do it like this instead:
use strict;
use warnings;
use Getopt::Std;
getopts( 'f:', \my %opt );
open INFILE, '', $opt{ f } or die $0 : failed to open input file $opt{f} : $!;
while ( INFILE ) {
print;
}
close INFILE;
__END__

John
--
use Perl;
program
fulfillment
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response



RE: Opening file($ARGV) with Getopt - failing

2004-09-28 Thread Bob Showalter
Errin Larsen wrote:
 So, what was the justification for changing 'use vars' to 'our'?

I don't know, but I suspect it's because our is a complement to my. Same
syntax (no silly qw() business), same lexical scoping, etc.

You're correct. our() should be used and 'use vars' should be considered
deprecated.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Opening file($ARGV) with Getopt - failing

2004-09-28 Thread Wiggins d Anconia
 On Tue, 28 Sep 2004, Errin Larsen wrote:
 
  On Tue, 28 Sep 2004 18:51:12 +0800, Edward Wijaya
  [EMAIL PROTECTED] wrote:
  
   use vars qw($f);
  
The above is good, but is now obsolete. 
 
 That is debatable.


Please, beginners, recognize the above word, *debatable*!!  I disagree
with the suggestion and feel that in many, many cases you will be better
off targeting newer features, especially since many times programs are
not distributed.  Once you get to a point of distribution, *and* someone
requests that you backport your script then make the change, it is just
as easy to go in reverse when necessary, than to deny yourself the use
of a tool that was added for good reason.  I don't expect my opinion to
be right, especially in all situations, but if you read this post then
you *need* to read the whole page that Chris linked to so that you can
see what other's thoughts were on the subject.
 
 Gather round, and listen to the story of a log handling utility 
 written in perl, and a frustrated user. He's not a perl programmer,
 he's a Solaris sysadmin. For him, perl is just a tool, just another
 language. And the version of perl shipped with his Solaris is
 5.005_03.
 
 He is disinclined to build and install a new version of perl just 
 to support a single tool. After all, he doesn't have to build
 new versions of awk, or new versions of C. Why should perl be any
 different?


Well then to me he is disinclined to use the tool, to each his own,
don't let the door hit you on the ass on the way out is an acceptable
answer, and often should be given more
 
 Trouble is, the author of this tool didn't agree. He had used 
 our variables instead of my. Which, of course, don't work in
 5.005_03. The user was quite prepared to ditch the tool altogether
 and find another because it didn't Just Work. I suggested that he
 go through it replacing our with my and lo and behold, it worked.
 

Of course, equating 'my' with 'our/use vars' we all know to be wrong...
don't we.

 The moral of this story is that even if you have the latest and 
 greatest perl, you shouldn't use the latest and greatest features
 unless you absolutely must. Because if you do you will severely
 limit who will use your code. our in particular is really only a
 convenience, saving a few key strokes at most. So don't use it. 
 Ever.
 

This is opinion taken out of context, and stated as a rule rather than a
suggestion, which may be a bit over the top.

 I'll buy a crate of beer for the first person who can show me some 
 real-world code which absolutely requires our and can't be 
 re-written to use my updateor use vars (cos I meant to say that 
 originally as well)/update.
 
 http://www.perlmonks.com/index.pl?node_id=393423
 
 The latest  greatest is only worth using if:
 

I disagree completely.  Two words, buffer overflow.  See an M$ bug
list for more If this were the case then we would all be writing in
assembly..

  * it really does offer you something you need
  * it really does offer you something that wasn't available before
  * you really don't have to worry about portability
  * there really aren't downsides to using it
 
 For most people, in most cases, one or more of these won't be true.
 
 It's worth it to be aware of the downsides of using a modern feature 
 like `our`, and to be confident that it really does make more sense to 
 use it over some older approach. It may be that the new ways really are 
 better -- I'm certainly not against progressing the language -- but if a 
 new feature breaks otherwise good code, is it worthwhile?
 

Definitely worth knowing about the downsides, but I would push the other
direction, is it worth not using something that benefits to prevent
something that may never happen?

 
 -- 
 Chris Devers
 

http://danconia.org

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Opening file($ARGV) with Getopt - failing

2004-09-28 Thread Chris Devers
On Tue, 28 Sep 2004, Wiggins d Anconia wrote:

 On Tue, 28 Sep 2004, Chris Devers wrote:
 
  On Tue, 28 Sep 2004, Errin Larsen wrote:
  
   On Tue, 28 Sep 2004 18:51:12 +0800, Edward Wijaya
   [EMAIL PROTECTED] wrote:
   
use vars qw($f);
   
 The above is good, but is now obsolete. 
  
  That is debatable.
 
 Please, beginners, recognize the above word, *debatable*!! 

aol /

I'm not forwarding this along as a blanket assertion that 'our' is bad, 
broken, and always to be avoided. None of that is true. Rather, I'm 
using it as an example of how a seemingly innocuous new feature can have 
unexpected  possibly hard to debug consequences in the wild. 

If you're only writing for yourself on systems that you have fulll 
control over, then this particular example probably isn't a big deal. 
If, on the other hand, you get a job where you have to work with the 
available software, then you may be stuck. 

It is worthwhile to spend a few minutes figuring out what problem a new 
feature solves, reflecting on whether that problem impacts you (chances 
are good that it does, but it might not), and considering whether or not 
using this new construct over older methods introduces new problems (it 
should not, but it might). 

To just blindly accept a suggestion like this without at least a little 
bit of thought is what is called cargo culting; it's a bad habit:

http://catb.org/~esr/jargon/html/C/cargo-cult-programming.html
http://www.physics.brocku.ca/etc/cargo_cult_science.html
http://en.wikipedia.org/wiki/Cargo_cult

That said, here's one article (of several, surely) that contrasts the 
'my' and 'our' functions:

http://perlmonks.thepen.com/105446.html

Be aware of what's going on here before concluding that 'our' is always 
the one to use. It might be, maybe, but it might not.

That's all :-)

  The moral of this story is that even if you have the latest and 
  greatest perl, you shouldn't use the latest and greatest features
  unless you absolutely must. Because if you do you will severely
  limit who will use your code. our in particular is really only a
  convenience, saving a few key strokes at most. So don't use it. 
  Ever.
  
 
 This is opinion taken out of context, and stated as a rule rather than a
 suggestion, which may be a bit over the top.

Maybe so, but I thought it was striking that Jokob Neilsen has written 
similar things about adopting new features in web design. Consider the 
footnote for this essay:

Normally, I advise against using new Web technologies for the first
year after they have been introduced. In most cases, using anything
new is asking for trouble and will alienate users with older browsers.

Link titles are an exception to the need to wait a year. First, their
use does not hurt users with browsers that don't display link titles
[] Second, a browser that does not understand link titles will
simply skip them. [] The only downside is that link titles will
add approximately 0.1 seconds to the download time for a typical
Web page over a modem connection. This is a rather harsh penalty,
but worth paying because of the increased navigation usability for
those users who do get to see the link titles.

At the time of this writing, link titles will probably only be seen
by 25% of the users. Normally, this would be insufficient to employ
a new Web technology, but since link titles are extremely easy to
add to your pages and since they do not pose any danger to users
with older browsers, it makes sense to go ahead and start using link
titles. []

http://www.useit.com/alertbox/980111.html

Note the way he thinks this through. The base instinct is conservative: 
most new features introduce problems bigger than the one they solve, so 
he avoids them. In this case, however, the problem is broad, the risks 
are slight, and the benefits are large, so he breaks the usual rule. 

That, I think, is the right approach to new features in any language. 

 Definitely worth knowing about the downsides, but I would push the 
 other direction, is it worth not using something that benefits to 
 prevent something that may never happen?

Beats me -- is it?

I don't think there's a blanket rule here, one way or the other. It 
comes down to what your expectations are for your code, whether or not 
it could have a life of its own after you're done with it, etc. 

If nothing else, it might not be bad to start off scripts using new 
features with a 

require 5.6.1;

(or whatever the first version with 'our' was), with a comment saying 
what construct you're using that demands the require statement. 


But anyway, I'll leave it at that, as this is turning into a long 
discussion with no real right or wrong sides but lots of talk... :-)

 

-- 
Chris Devers

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ 

Getopt::Std vs. Getopt::Long

2004-07-14 Thread perl.org
I have been using Getopt::Std for some time and I'm pretty happy with it. 
I've been reading about Getopt::Long and it seems to support everything in
Getopt::Std and has some nice conveniences.  Does anyone have experience
converting scripts (or just development process) from Std to Long?  Does
anyone have pretty good code examples using Getopt::Long?

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




  1   2   3   >