RE: slurping function like shell
R. Joseph Newton wrote: > The die function can be very useful > working in console mode, but it is hell for CGI debugging. > Since errors go into the server error log, which tends to be > accessible only to the system admin, it can be damn near > useless to have die statements in a CGI script. You might want to investigate CGI::Carp for an approach to this problem. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Harry Putnam wrote: > > "John W. Krahn" <[EMAIL PROTECTED]> writes: > > > You shouldn't use ampersands unless you need the different behavior they > > provide. > > John, > I asked for a documentation pointer on this in a previous post that > hasn't hit the server here yet, but don't bother with that please. I > found the info in perlfaq7... thanks. perlsub contains the documentation on Perl's subroutines and should answer all your questions. :-) perldoc perlsub John -- use Perl; program fulfillment -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
" ... > open(FILE,">somefile") or die "Cannot open 'somefile' $!"; Not being argumentative here but I've seen this said before. Not really sure why it is important. I mean why is the open action singled out for this protection. It seems other actions could also cause a misfired script? ..." --Harry Hi Harry, Your scepticism is appropriate here, although possibly for the wrong reason. The die function can be very useful working in console mode, but it is hell for CGI debugging. Since errors go into the server error log, which tends to be accessible only to the system admin, it can be damn near useless to have die statements in a CGI script. File opening is particularly vulnerable to forces external to your program compared with other operations. The basic concept is that if you don't have a source for your information, you have nothing to go on. Still, unless further activity in your scri8pt can be destructive of data, it may not be necessary to die. For cont3exts where die leaves me without sufficient information for debugging, I prefer print: open (NEWMEMBERS, "< newmember.txt" or print " Sorry, file newmembers.txt did not open because $!\n"; Of course, I am now in debugging mode. Before I release my CGI for public use, I will probably substitue a cleanup function: $FileName = "newmember.txt" open (NEWMEMBERS, "< $FileName" or SignalOpenFailureAndDie($FileName, $!); where SignalOpenFailureAndDie() prints a page briefly explaining to the user why they are not getting expected results. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Ben Siders <[EMAIL PROTECTED]> writes: > You should always perform all error checking in any language to ensure Well thanks Ben. That was nice full explanation and makes a lot of sense. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
strftime is an interface to a C function of the same name. It's a fairly common function in many applications that have to deal with dates and times. You may not need it here, but it's not a bad idea to get a little familiar with it. For the life of me, I can't ever remember all the format characters, so I wouldn't sweat those kinds of details. 'man strftime' provides you with easy access to a well-organized list on almost any UNIX-like OS. I don't know which would be easier for your specific case, but I like to encourage people to look into all the options. Most of the format characters are intuitive, and there's some "shortcuts" to common formats. I use this function specifically for timestamps on log messages because its versatile, fast, and simple. Honestly. :) Harry Putnam wrote: "John W. Krahn" <[EMAIL PROTECTED]> writes: You should probably be using POSIX::strftime instead which is simpler and faster. use POSIX 'strftime'; print FILE strftime( "An extra numeral <%D %T %w> appears\n", localtime ); Probably coming off like some kind of carpy here but I'm puzzled by this. Its a nice tip and new material for me to use. But I don't really see how its easier. I'm guessing you say `easier' because its already written and all I have to do is call it in and know the syntax. Using this approach I'm required to remember the syntax for calling strftime and the strftime operators when ever I need a specialized date format. Even if its usually the same one I want. I had in mind a dating subroutine I could call that gives a dating string I prefer in most cases (for log lines etc). Without having to remember date operators or other syntax. Just its name. That is, I would look up the operators once. Put them in the function and not ever think about them again. To use the strftime example like that would require something similar ie, writing a function that calls it in just the right way using strftime, when ever needed. In that case it seems it would be about par either way. My knowledge of perl is not very deep so I may be missing other obvious advantages. I mean besides the mentioned speed factor. -- Benjamin J. Siders Software Engineer -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
"John W. Krahn" <[EMAIL PROTECTED]> writes: > You shouldn't use ampersands unless you need the different behavior they > provide. John, I asked for a documentation pointer on this in a previous post that hasn't hit the server here yet, but don't bother with that please. I found the info in perlfaq7... thanks. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
"John W. Krahn" <[EMAIL PROTECTED]> writes: > You should probably be using POSIX::strftime instead which is simpler > and faster. > > use POSIX 'strftime'; > > print FILE strftime( "An extra numeral <%D %T %w> appears\n", > localtime ); Probably coming off like some kind of carpy here but I'm puzzled by this. Its a nice tip and new material for me to use. But I don't really see how its easier. I'm guessing you say `easier' because its already written and all I have to do is call it in and know the syntax. Using this approach I'm required to remember the syntax for calling strftime and the strftime operators when ever I need a specialized date format. Even if its usually the same one I want. I had in mind a dating subroutine I could call that gives a dating string I prefer in most cases (for log lines etc). Without having to remember date operators or other syntax. Just its name. That is, I would look up the operators once. Put them in the function and not ever think about them again. To use the strftime example like that would require something similar ie, writing a function that calls it in just the right way using strftime, when ever needed. In that case it seems it would be about par either way. My knowledge of perl is not very deep so I may be missing other obvious advantages. I mean besides the mentioned speed factor. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
You should always perform all error checking in any language to ensure that your program, if it fails, declines gracefully. One of the greatest shortcomings of C is that error checking is entirely manual, and you simply must, in every real-world application, check the return value of almost every function. Perl is no different. If the result of the statement fails in such a way that your program cannot continue, you must check for the error and deal with it appropriately. If you need to write the output of the program to a file and it can't be opened, then you need to print it to the terminal or abort, or both, or at least inform the user of the condition. People single out open probably because it's so common and when it fails it's almost always a show-stopping error. Ultimately, in good programming practice, you should sanity check the result of any function that could make or break your application. There are, obviously, some exceptions (I had to build a C program once for which speed was the #1 priority, which meant going light on error checking ), but that's just a good general rule. Harry Putnam wrote: Thanks for tips posters.. "John W. Krahn" <[EMAIL PROTECTED]> writes: You should _always_ verify that the file opened successfully. open(FILE,">somefile") or die "Cannot open 'somefile' $!"; Not being argumentative here but I've seen this said before. Not really sure why it is important. I mean why is the open action singled out for this protection. It seems other actions could also cause a misfired script? print FILE "An extra numeral <" . &lctime . "> appears\n"; ^ You shouldn't use ampersands unless you need the different behavior they provide. print FILE "An extra numeral <" . lctime() . "> appears\n"; I use them simply for recognition in my own code. I wasn't aware of different behavior from the () indicator. Can you aim me at some documentation for elaboration? You should probably be using POSIX::strftime instead which is simpler and faster. Thanks. -- Benjamin J. Siders Software Engineer -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Thanks for tips posters.. "John W. Krahn" <[EMAIL PROTECTED]> writes: > You should _always_ verify that the file opened successfully. > > open(FILE,">somefile") or die "Cannot open 'somefile' $!"; Not being argumentative here but I've seen this said before. Not really sure why it is important. I mean why is the open action singled out for this protection. It seems other actions could also cause a misfired script? >> print FILE "An extra numeral <" . &lctime . "> appears\n"; > ^ > You shouldn't use ampersands unless you need the different behavior they > provide. > > print FILE "An extra numeral <" . lctime() . "> appears\n"; I use them simply for recognition in my own code. I wasn't aware of different behavior from the () indicator. Can you aim me at some documentation for elaboration? > You should probably be using POSIX::strftime instead which is simpler > and faster. Thanks. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Harry Putnam wrote:
>
> Maybe unrelated to the comments above since this is `do' I'm posting
> about in this post. But I'm still seeing something here I don't
> understand.
>
> I'll use my reall example code since that is where I notice this
> phenomena.
>
> My function to slurp looks like:
>
> cat /home/hgp/scripts/perl/fnc/lctime
>
> sub lctime {
> ## Fucntion to create a date in my preferred format
> @lta = localtime;
> ## Adjust for mnth range of 0-11
> $lta[4] += 1;
> ## Adjust for year based on 1900, and remove leading 2 digits so
> ## 103 first becomes 2003 and then 03
> ($lta[5] = ($lta[5] += 1900)) =~ s/^..//;
You could use the modulus operator instead of the substitution.
$lta[5] %= 100;
> ## Print it out in this format:
> ## mnthdayyr hr:min:sec wkday (padding with zeros where necessary)
> ## Like 012003 15:15:51 01
> printf "%02d%02d%02d %02d:%02d:%02d %02d\n", @lta[4,3,5,2,1,0,6];
Perl subs return the value of the last expression in the sub which in
this case is printf() which returns 1 (true) on success. You want to
return the actual string using sprintf().
sprintf "%02d%02d%02d %02d:%02d:%02d %02d\n", @lta[4,3,5,2,1,0,6];
> }
>
> How can I print the output of this into a file handle?
>
> When I try, I get an extra numeral 1 which I'm guessing is a return
> value from misguided referencing.
>
> Example:
>
> #!/usr/local/bin/perl -w
> do "/home/hgp/scripts/perl/fnc/lctime";
> open(FILE,">somefile");
You should _always_ verify that the file opened successfully.
open(FILE,">somefile") or die "Cannot open 'somefile' $!";
> print FILE "An extra numeral <" . &lctime . "> appears\n";
^
You shouldn't use ampersands unless you need the different behavior they
provide.
print FILE "An extra numeral <" . lctime() . "> appears\n";
You should probably be using POSIX::strftime instead which is simpler
and faster.
use POSIX 'strftime';
print FILE strftime( "An extra numeral <%D %T %w> appears\n",
localtime );
John
--
use Perl;
program
fulfillment
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
You are actually not explicitly returning anything from the lctime
subroutine, which means that implicitly perl will return the last return
value of what happened in lctime.
Here is what you need to do:
* Change your printf to sprintf (i assume sprintf is what you really
want)
* put a explicit return in.
aka,
sub lctime {
...
...
return sprintf(...);
}
At the moment your printf statement is returning "true" (or '1') which
is the reason you are having '1' printed.
simran.
On Tue, 2003-01-21 at 14:01, Harry Putnam wrote:
> Wiggins d'Anconia <[EMAIL PROTECTED]> writes:
>
> > "The file must return true as the last statement to indicate
> > successful execution of any initialization code, so its customary to
> > end such a file with "1;" unless youre sure itll return true
> > otherwise. But its better just to put the "1;", in case you add more
> > statements."
>
> Maybe unrelated to the comments above since this is `do' I'm posting
> about in this post. But I'm still seeing something here I don't
> understand.
>
> I'll use my reall example code since that is where I notice this
> phenomena.
>
> My function to slurp looks like:
>
> cat /home/hgp/scripts/perl/fnc/lctime
>
> sub lctime {
> ## Fucntion to create a date in my preferred format
> @lta = localtime;
> ## Adjust for mnth range of 0-11
> $lta[4] += 1;
> ## Adjust for year based on 1900, and remove leading 2 digits so
> ## 103 first becomes 2003 and then 03
> ($lta[5] = ($lta[5] += 1900)) =~ s/^..//;
> ## Print it out in this format:
> ## mnthdayyr hr:min:sec wkday (padding with zeros where necessary)
> ## Like 012003 15:15:51 01
> printf "%02d%02d%02d %02d:%02d:%02d %02d\n", @lta[4,3,5,2,1,0,6];
> }
>
> How can I print the output of this into a file handle?
>
> When I try, I get an extra numeral 1 which I'm guessing is a return
> value from misguided referencing.
>
> Example:
>
> #!/usr/local/bin/perl -w
> do "/home/hgp/scripts/perl/fnc/lctime";
> open(FILE,">somefile");
> print FILE "An extra numeral <" . &lctime . "> appears\n";
>
> cat somefile
> An extra numeral <1> appears
>
> But the output of &lctime goes to tty.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Wiggins d'Anconia <[EMAIL PROTECTED]> writes:
> "The file must return true as the last statement to indicate
> successful execution of any initialization code, so its customary to
> end such a file with "1;" unless youre sure itll return true
> otherwise. But its better just to put the "1;", in case you add more
> statements."
Maybe unrelated to the comments above since this is `do' I'm posting
about in this post. But I'm still seeing something here I don't
understand.
I'll use my reall example code since that is where I notice this
phenomena.
My function to slurp looks like:
cat /home/hgp/scripts/perl/fnc/lctime
sub lctime {
## Fucntion to create a date in my preferred format
@lta = localtime;
## Adjust for mnth range of 0-11
$lta[4] += 1;
## Adjust for year based on 1900, and remove leading 2 digits so
## 103 first becomes 2003 and then 03
($lta[5] = ($lta[5] += 1900)) =~ s/^..//;
## Print it out in this format:
## mnthdayyr hr:min:sec wkday (padding with zeros where necessary)
## Like 012003 15:15:51 01
printf "%02d%02d%02d %02d:%02d:%02d %02d\n", @lta[4,3,5,2,1,0,6];
}
How can I print the output of this into a file handle?
When I try, I get an extra numeral 1 which I'm guessing is a return
value from misguided referencing.
Example:
#!/usr/local/bin/perl -w
do "/home/hgp/scripts/perl/fnc/lctime";
open(FILE,">somefile");
print FILE "An extra numeral <" . &lctime . "> appears\n";
cat somefile
An extra numeral <1> appears
But the output of &lctime goes to tty.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Harry Putnam <[EMAIL PROTECTED]> writes: > Ick... I flew right over that about the `1' in perldoc -f require. > Always was confused by the term `return'. I guess its pretty basic > to programmers but to us lifetime heavy construction workers it can > be a bit mysterious. > > Thanks for the guidance. You and Bob have added a whole new layer of usefullness for me tonight. I've thrashed around with that function slurping stuff quite a few times but never really got it. I'd been avoiding trying to write my own *.pm files because, somewhere I got the notion that *.pm files were nasty complex creatures that required acres of special syntax and formatting. I'm very pleased with my query this evening and glad to find out I can get some use out of `use' (har har) beyond that afforded by other folks *.pm files. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Wiggins d'Anconia <[EMAIL PROTECTED]> writes: > Sorry "customary" (as the perldoc for require states) is a better word > than "standard". From perldoc -f require: Ick... I flew right over that about the `1' in perldoc -f require. Always was confused by the term `return'. I guess its pretty basic to programmers but to us lifetime heavy construction workers it can be a bit mysterious. Thanks for the guidance. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Wiggins d'Anconia wrote: Harry Putnam wrote: pfnc.pm did not return a true value at ./use.pl line 2. BEGIN failed--compilation aborted at ./use.pl line 2. Place a line such as: 1; In the bottom of the library so that it "returns true". This is standard. http://danconia.org Sorry "customary" (as the perldoc for require states) is a better word than "standard". From perldoc -f require: "The file must return true as the last statement to indicate successful execution of any initialization code, so its customary to end such a file with "1;" unless youre sure itll return true otherwise. But its better just to put the "1;", in case you add more statements." http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Harry Putnam wrote: pfnc.pm did not return a true value at ./use.pl line 2. BEGIN failed--compilation aborted at ./use.pl line 2. Place a line such as: 1; In the bottom of the library so that it "returns true". This is standard. http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Wiggins d'Anconia <[EMAIL PROTECTED]> writes:
[...]
> 'use' can be as simple or complex as you wish really. The only thing
> slightly more complicated is if @INC doesn't contain where your *.pm
> lives. But that would be a simple case of doing
>
> use lib ('/path/to/libs/');
>
> before your other use MyModule call. Of course you could be after the
> 'about as simple as it gets' 'require', so:
Bob Showalter <[EMAIL PROTECTED]> writes:
> There are several functions:
>
>perldoc -f do
>perldoc -f require
>perldoc -f use
Ahh I see how to do something sort of like slurping functinos ala shell
technique here with `use' and `require'. But different.
The `do' function seems to be the closest thing to the shell dot (.)
operator. Thanks.
Going a bit further here... It seems `use' and `require' have to have
more to work.
For example:
With these files in /usr/lib/perl5/site_perl/
(both files have the same content)
5.8.0/ pfnc pfnc.pm
cat use.pl
#!/usr/local/bin/perl -w
use pfnc;
print "trying function\n"
&lctime_ar;
cat require.pl
#!/usr/local/bin/perl -w
require "pfnc";
print "trying function\n";
&lctime_ar;
cat pfnc:
sub lctime_ar{
@ar = localtime;
$cnt = 0;
for(@ar){
print "Ele [$cnt] = $_\n";
$cnt++;
}
}
(ditto for pfnc.pm)
Results:
./use.pl
pfnc.pm did not return a true value at ./use.pl line 2.
BEGIN failed--compilation aborted at ./use.pl line 2.
./require.pl
pfnc did not return a true value at ./require.pl line 2.
But if I put a call to the function in the pfnc source file. It
works. But doesn't remember the function. and gives some warnings.
cat pfnc.pm
&lctime_ar;
sub lctime_ar{
@ar = localtime;
$cnt = 0;
for(@ar){
print "Ele [$cnt] = $_\n";
$cnt++;
}
}
Results:
use.pl
Ele [0] = 31
Ele [1] = 19
Ele [2] = 16
Ele [3] = 20
Ele [4] = 0
Ele [5] = 103
Ele [6] = 1
Ele [7] = 19
Ele [8] = 0
pfnc.pm did not return a true value at ./use.pl line 2.
BEGIN failed--compilation aborted at ./use.pl line 2.
./require.pl
Ele [0] = 31
Ele [1] = 26
Ele [2] = 16
Ele [3] = 20
Ele [4] = 0
Ele [5] = 103
Ele [6] = 1
Ele [7] = 19
Ele [8] = 0
pfnc did not return a true value at ./require.pl line 2.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: slurping function like shell
Harry Putnam wrote: > I know this is a horse that has been ridden hard before, but not so > easy to find the results. > > How does one slurp a function or series of functions in perl? > Similar to the way its done in shells': >. somefunction > > I know about the: > use (some.pm file); > > syntax, of course, but it seems to entail lots of extra details and > knowledge, compared to the shell technique. Is there something > comparably simple that allows perl scripts to slurp functions from a > central source? There are several functions: perldoc -f do perldoc -f require perldoc -f use See "perldoc -q require" for a good overview of the different techniques. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: slurping function like shell
Harry Putnam wrote:
I know this is a horse that has been ridden hard before, but not so
easy to find the results.
How does one slurp a function or series of functions in perl?
Similar to the way its done in shells':
. somefunction
I know about the:
use (some.pm file);
syntax, of course, but it seems to entail lots of extra details and
knowledge, compared to the shell technique. Is there something
comparably simple that allows perl scripts to slurp functions from a
central source?
'use' can be as simple or complex as you wish really. The only thing
slightly more complicated is if @INC doesn't contain where your *.pm
lives. But that would be a simple case of doing
use lib ('/path/to/libs/');
before your other use MyModule call. Of course you could be after the
'about as simple as it gets' 'require', so:
perldoc -f require
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
slurping function like shell
I know this is a horse that has been ridden hard before, but not so easy to find the results. How does one slurp a function or series of functions in perl? Similar to the way its done in shells': . somefunction I know about the: use (some.pm file); syntax, of course, but it seems to entail lots of extra details and knowledge, compared to the shell technique. Is there something comparably simple that allows perl scripts to slurp functions from a central source? -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
