Re: Hi a question
Daniel, For only 4 variables, I thought it was overkill to have an ini file. However as I continue to mess around with my code, I'm adding more and more externalized variables. Use of an ini is becoming more appealing. Thanks for your thoughts! On Sun, 28 Dec 2003, Daniel Staal wrote: Personal opinion: A cfg file is much easier to update/maintain then environment variables, and a command line is easier to use for 'variable' setups. For a case like this I would probably want to use a combined commandline/config file setup. Luckily, that only requires *one* CPAN module: AppConfig. It will handle both, in either order. Daniel T. Staal -- Maranatha! John McKown -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Hi a question
On Dec 31, 2003, at 8:28 AM, John McKown wrote: For only 4 variables, I thought it was overkill to have an ini file. However as I continue to mess around with my code, I'm adding more and more externalized variables. Use of an ini is becoming more appealing. john, for what it is worth - cf: http://www.wetware.com/drieux/PR/blog2/Code/200312.html#id3155628391 in it I have references to two pieces of demonstration code that you might want to think about as tactics in this type of problem. ciao drieux --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Hi a question
On Dec 26, 2003, at 9:37 AM, John McKown wrote: [..] E.g. export DIR1=... export DIR2=... export IPADDR=... export IPPORT=... perl-script.perl or perl-script.perl DIR1 DIR2 IPADDR IPPORT [..] Thanks for the seasonal ranting option: http://www.wetware.com/drieux/PR/blog2/Code/200312.html#id3155542177 I must confess that I find it rather ironic that you started with environmental variables rather than positional arguments. I would of course recommend that you start with perldoc Getopt::Long One of my more demented variants is up at: http://www.wetware.com/drieux/pbl/perlTrick/CommandLine/ do_get_opt_long.txt But what I think you will really want to get in touch with is the idea of a configuration file, either as a 'default preference' file, if this is really going to be an application layer programme - or in the more traditional set of issues related to writing daemons and configuration files for them. ciao drieux --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Hi a question
--As off Friday, December 26, 2003 3:16 PM -0600, John McKown is alleged to have said: Actually, I considered an ini or cfg file, but rejected it. I was wanting something more standalone in this case. First, it seemed a bit much for only 4 parms. Second, I didn't want to maintain a separate file. Third, I didn't want to parse an ini file, although there is likely a CPAN module around to do that. And I already use LWP::UserAgent and HTTP::Request::Common, so requiring another CPAN modules is not really a big deal. I really appreciate CPAN! --As for the rest, it is mine. Personal opinion: A cfg file is much easier to update/maintain then environment variables, and a command line is easier to use for 'variable' setups. For a case like this I would probably want to use a combined commandline/config file setup. Luckily, that only requires *one* CPAN module: AppConfig. It will handle both, in either order. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
RE: Hi a question
hey !!! do you celebrate only perl even in the christmas vacation !!! Take a break !! Have a kit kat christmas cake. Merry Christmas to this perl group Rajeev -Original Message- From: John McKown [mailto:[EMAIL PROTECTED] Sent: Friday, December 26, 2003 11:08 PM To: Perl Beginners Mailing List Subject: Hi a question I'm new here and a very novice Perl coder. And I have a question, of course grin. Is it more Perl-like to get information from the shell via UNIX Environment Variables or via the command line? For an example, I have writing a Perl program which reacts to messages sent to it. It has four input parameters. The current program gets this information, which is two distinct subdirectories, a port number, and an IP address, via four different environment variables. My question is should I do it that way or should I pass this information in via the command line. E.g. export DIR1=... export DIR2=... export IPADDR=... export IPPORT=... perl-script.perl or perl-script.perl DIR1 DIR2 IPADDR IPPORT Although my current code uses the first way, I'm beginning to think that the second is preferrable because it would be more portable to non-UNIX environments. I hope everybody is having a good holiday. -- Maranatha! John McKown -- 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: Hi a question
Why not just make DIR1, DIR2, IPADDR AND IPPORT global variables within the script, rather then requiring user to set env variables, which can become a pain in the ass. Your best bet would be to set them to some default variable, and then if the user needs to, she can override the default values by passing the new values as parameters. Hope that helps. Steven Kreuzer Linux Systems Administrator Etagon, Inc W: 646.728.0656 F: 646.728.0607 E: [EMAIL PROTECTED] -Original Message- From: John McKown [mailto:[EMAIL PROTECTED] Sent: Friday, December 26, 2003 12:38 PM To: Perl Beginners Mailing List Subject: Hi a question I'm new here and a very novice Perl coder. And I have a question, of course grin. Is it more Perl-like to get information from the shell via UNIX Environment Variables or via the command line? For an example, I have writing a Perl program which reacts to messages sent to it. It has four input parameters. The current program gets this information, which is two distinct subdirectories, a port number, and an IP address, via four different environment variables. My question is should I do it that way or should I pass this information in via the command line. E.g. export DIR1=... export DIR2=... export IPADDR=... export IPPORT=... perl-script.perl or perl-script.perl DIR1 DIR2 IPADDR IPPORT Although my current code uses the first way, I'm beginning to think that the second is preferrable because it would be more portable to non-UNIX environments. I hope everybody is having a good holiday. -- Maranatha! John McKown -- 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: Hi a question
I'm not a 'perl' pro, but I am a pro at using different shells, programs and so on in different environments. It depends on the environment in which you're running. For example, running on some type of *NIX at a command line, you might very well want command line options so that people and scripts can easily change the arguments (it is a pain to change environment variables ... more typing and saving and exporting and what not). However, if your perl script is called from other perl scripts (since people aren't typing it), you may want to change the environment. Of course, you may want to hide the arguments, in which case, variables in a file readable by the script would be the choice, so that no one could see the arguments (*NIX ps -elf) or the environment (*NIX ps axe). IMHO, it really depends on what the best use is ... how much a pain ... what's the protection ... do different people need different environments but NEVER change it once they have that environment (the case for Environment variables) ... etc. I don't run much under M$ Windows, but that may very well point you in a particular direction, based on what's easily available. Bruce T. Harvey Legg Mason Wood Walker, Inc. Corporate Technology - UNIX Admin. Red Run 2nd Floor - Owings Mills, MD (410) 580-7383 - [EMAIL PROTECTED] --- -Original Message- From: John McKown [mailto:[EMAIL PROTECTED] Sent: Friday, December 26, 2003 12:38 PM To: Perl Beginners Mailing List Subject: Hi a question I'm new here and a very novice Perl coder. And I have a question, of course grin. Is it more Perl-like to get information from the shell via UNIX Environment Variables or via the command line? For an example, I have writing a Perl program which reacts to messages sent to it. It has four input parameters. The current program gets this information, which is two distinct subdirectories, a port number, and an IP address, via four different environment variables. My question is should I do it that way or should I pass this information in via the command line. E.g. export DIR1=... export DIR2=... export IPADDR=... export IPPORT=... perl-script.perl or perl-script.perl DIR1 DIR2 IPADDR IPPORT Although my current code uses the first way, I'm beginning to think that the second is preferrable because it would be more portable to non-UNIX environments. I hope everybody is having a good holiday. -- Maranatha! John McKown IMPORTANT: The security of electronic mail sent through the Internet is not guaranteed. Legg Mason therefore recommends that you do not send confidential information to us via electronic mail, including social security numbers, account numbers, and personal identification numbers. Delivery, and timely delivery, of electronic mail is also not guaranteed. Legg Mason therefore recommends that you do not send time-sensitive or action-oriented messages to us via electronic mail, including authorization to buy or sell a security or instructions to conduct any other financial transaction. Such requests, orders or instructions will not be processed until Legg Mason can confirm your instructions or obtain appropriate written documentation where necessary. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Hi a question
Pandey Rajeev-A19514 wrote: hey !!! do you celebrate only perl even in the christmas vacation !!! Take a break !! Have a kit kat christmas cake. Merry Christmas to this perl group Rajeev I might remind you--not everyone even celbrates that particular holiday. I join my family in the celebration, and finds that it works fine that way as a celebration of the solstice. I cetainly don't feel, though, that I have to stop creative engagements, to celbrate a holiday. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Hi a question
John McKown wrote: I'm new here and a very novice Perl coder. And I have a question, of course grin. Is it more Perl-like to get information from the shell via UNIX Environment Variables or via the command line? For an example, I have writing a Perl program which reacts to messages sent to it. It has four input parameters. The current program gets this information, which is two distinct subdirectories, a port number, and an IP address, via four different environment variables. My question is should I do it that way or should I pass this information in via the command line. E.g. export DIR1=... export DIR2=... export IPADDR=... export IPPORT=... perl-script.perl or perl-script.perl DIR1 DIR2 IPADDR IPPORT Although my current code uses the first way, I'm beginning to think that the second is preferrable because it would be more portable to non-UNIX environments. I hope everybody is having a good holiday. -- Maranatha! John McKown Hi John, I'd suggest that both approaches can be somewhat lacking in portability. The command line is something of a kludge, IMHO, as it still depends largely on users typing in the correct parameters. I think ini files would be portable across a much wider variety of systems. Just write the ini file per installation configuration. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: Hi a question
On Fri, 26 Dec 2003, R. Joseph Newton wrote: Hi John, I'd suggest that both approaches can be somewhat lacking in portability. The command line is something of a kludge, IMHO, as it still depends largely on users typing in the correct parameters. I think ini files would be portable across a much wider variety of systems. Just write the ini file per installation configuration. Joseph Actually, I considered an ini or cfg file, but rejected it. I was wanting something more standalone in this case. First, it seemed a bit much for only 4 parms. Second, I didn't want to maintain a separate file. Third, I didn't want to parse an ini file, although there is likely a CPAN module around to do that. And I already use LWP::UserAgent and HTTP::Request::Common, so requiring another CPAN modules is not really a big deal. I really appreciate CPAN! -- Maranatha! John McKown -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
RE: Hi all, question about caracter detection
Hi All,
thankx for the help (Sudarshan Raghavan and Beau E.
Cox), i have found a generic solution
here is the sample script...
#
#!/usr/bin/perl -wT
##
# modules
##
use strict ;
##
# Global Variables
##
#
# will recive a string are check agains a list of
allowed values
# Will return : 0 if only allowed chars were found
# 1 if at least one invalid char is
found
sub check_string {
unless ( $_[0] =~ m/[^a-zA-Z0-9]/ ) {
return 0;
}
return 1;
}
##
# Main
##
my $STRING = askdnj\nasj;
print \n(0 is ok, 1 means invalid chars) : ;
print check_string($STRING);
print \n;
###
Stay well all
Miguel Angelo
--- Sudarshan Raghavan [EMAIL PROTECTED] wrote:
On Mon, 18 Nov 2002, Beau E. Cox wrote:
Hi -
This will 'strip' all but a-zA-Z0-9:
#!/usr/bin/perl
use strict;
use warnings;
my $STRING = kjsh234Sd\nki;
$STRING =~ s/[^a-zA-Z0-9]//sg;
print $STRING\n;
the ~ makes the character class negative,
I guess you meant ^, not ~
the s makes
the regex examine new lines, and g means global.
You need an /s when you want . to match newlines
(which it
normally doesn't). In this case since you are not
using a
.., /s is not needed.
$STRING =~ s/[^a-zA-Z0-9]//g;
The above will work just fine
You can also use tr/// for this
$STRING =~ tr/a-zA-Z0-9//cd;
If the OP just wants to check not replace either of
these should
do
unless ($STRING =~ m/[^a-zA-Z0-9]/) {
# Valid STRING
}
or
unless ($STRING =~ tr/a-zA-Z0-9//c) {
# Valid STRING
}
--
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
=
*
* Miguel Angelo *
* E-mail: [EMAIL PROTECTED] *
* Domain: http://migas.mine.nu *
*
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hi all, question about caracter detection
You could also use
return $_[0] !~ m/[^a-zA-Z0-9]/;
or
return $_[0] =~ m/^[a-zA-Z0-9]+\Z/;
the last one is clearer to me because you eliminate all of the negatives.
- Original Message -
From: Miguel Angelo [EMAIL PROTECTED]
To: Perl beginners [EMAIL PROTECTED]
Sent: Friday, November 22, 2002 3:34 PM
Subject: RE: Hi all, question about caracter detection
Hi All,
thankx for the help (Sudarshan Raghavan and Beau E.
Cox), i have found a generic solution
here is the sample script...
#
#!/usr/bin/perl -wT
##
# modules
##
use strict ;
##
# Global Variables
##
#
# will recive a string are check agains a list of
allowed values
# Will return : 0 if only allowed chars were found
# 1 if at least one invalid char is
found
sub check_string {
unless ( $_[0] =~ m/[^a-zA-Z0-9]/ ) {
return 0;
}
return 1;
}
##
# Main
##
my $STRING = askdnj\nasj;
print \n(0 is ok, 1 means invalid chars) : ;
print check_string($STRING);
print \n;
###
Stay well all
Miguel Angelo
--- Sudarshan Raghavan [EMAIL PROTECTED] wrote:
On Mon, 18 Nov 2002, Beau E. Cox wrote:
Hi -
This will 'strip' all but a-zA-Z0-9:
#!/usr/bin/perl
use strict;
use warnings;
my $STRING = kjsh234Sd\nki;
$STRING =~ s/[^a-zA-Z0-9]//sg;
print $STRING\n;
the ~ makes the character class negative,
I guess you meant ^, not ~
the s makes
the regex examine new lines, and g means global.
You need an /s when you want . to match newlines
(which it
normally doesn't). In this case since you are not
using a
.., /s is not needed.
$STRING =~ s/[^a-zA-Z0-9]//g;
The above will work just fine
You can also use tr/// for this
$STRING =~ tr/a-zA-Z0-9//cd;
If the OP just wants to check not replace either of
these should
do
unless ($STRING =~ m/[^a-zA-Z0-9]/) {
# Valid STRING
}
or
unless ($STRING =~ tr/a-zA-Z0-9//c) {
# Valid STRING
}
--
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
=
*
* Miguel Angelo *
* E-mail: [EMAIL PROTECTED] *
* Domain: http://migas.mine.nu *
*
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hi all, question about caracter detection
Hi -
This will 'strip' all but a-zA-Z0-9:
#!/usr/bin/perl
use strict;
use warnings;
my $STRING = kjsh234Sd\nki;
$STRING =~ s/[^a-zA-Z0-9]//sg;
print $STRING\n;
the ~ makes the character class negative, the s makes
the regex examine new lines, and g means global.
Aloha - Beau.
-Original Message-
From: Miguel Angelo [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 18, 2002 2:31 AM
To: [EMAIL PROTECTED]
Subject: Hi all, question about caracter detection
Hi All,
Thankx for reading this.
I have a very newbie question...
i'm working on a CGI and i want only to permit some
caracters by the user...
imagine
my $STRING = kjsh234Sd\nki;
# now i want to check if there is any invalid caracter
# in this case a-z ; A-Z and 0-9
there for /[a-zA-Z0-9]/ but i am unable to find a
valid command for that, the \n always passes, i
definity do not want to use execption on what o do not
allow, i want only to allow some caracters
invalidating all others...
here what i have tried
if ( $STRING =~ /[a-zA-Z0-9]/ ) { etc }
my $count = ( $STRING =~ tr /a-zA-Z0-9// );
all failed...
please help me :)
=
*
* Miguel Angelo *
* E-mail: [EMAIL PROTECTED] *
* Domain: http://migas.mine.nu *
*
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Hi all, question about caracter detection
On Mon, 18 Nov 2002, Beau E. Cox wrote:
Hi -
This will 'strip' all but a-zA-Z0-9:
#!/usr/bin/perl
use strict;
use warnings;
my $STRING = kjsh234Sd\nki;
$STRING =~ s/[^a-zA-Z0-9]//sg;
print $STRING\n;
the ~ makes the character class negative,
I guess you meant ^, not ~
the s makes
the regex examine new lines, and g means global.
You need an /s when you want . to match newlines (which it
normally doesn't). In this case since you are not using a
.., /s is not needed.
$STRING =~ s/[^a-zA-Z0-9]//g;
The above will work just fine
You can also use tr/// for this
$STRING =~ tr/a-zA-Z0-9//cd;
If the OP just wants to check not replace either of these should
do
unless ($STRING =~ m/[^a-zA-Z0-9]/) {
# Valid STRING
}
or
unless ($STRING =~ tr/a-zA-Z0-9//c) {
# Valid STRING
}
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hi, newbie question
In vi, you have to type ctrl-v ctrl-m. This will tell vi you mean control-m and not carrot-m. :%s/ctrl-vcrtl-m//g =-= Robert Thompson Even in vi when i do a search for ^M by doing '/^M' it says that no matches were found. The ^M is not two characters but one. Can anyone out there please help me? -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hi, newbie question
On Mon, 2002-07-22 at 14:41, Desmond Lee wrote: Hi guys I'm trying to read a file, but it's just one massive line. I think that the ^M is suppose to be an indication that that's wehre teh newline is suppose to be. I've tried to replace ^M with a newline by executing something that i found on the web: perl -pi.bak -e 's/\^M/\n/g' moby_threads_install.txt try: perl -pi.bak -e 's/\r/\n/g' moby_threads_install.txt -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hi, newbie question
Hello, I don't think that the file matters. You say it's a massive line. To read a file you should first open it. Look at PerlDoc. Desmond Lee [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi guys I'm trying to read a file, but it's just one massive line. I think that the ^M is suppose to be an indication that that's wehre teh newline is suppose to be. I've tried to replace ^M with a newline by executing something that i found on the web: perl -pi.bak -e 's/\^M/\n/g' moby_threads_install.txt This didn't work. Even in vi when i do a search for ^M by doing '/^M' it says that no matches were found. The ^M is not two characters but one. Can anyone out there please help me? Thanks Desmond _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
