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
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
" ...
> 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?
..."
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]
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 c
"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 perlf
"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
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 ev
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 import
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:
>
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
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;",
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 guida
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 bas
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
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
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
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);
>
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,
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
20 matches
Mail list logo
