trapping file i/o error

[toylet]

In most perl examples, it used this method to trap error:

open(INFILE, $fname) or die "Unable to open $fname";
process_file();
close(INFILE)
other_codes();

Now that if I don't want to die after the open so as to run
other_codes()? Could I test the value of file handle INFILE like what I
did with C?

fhandle=fopen(f name,"r")
if (fhandle > 0) {
process_file();
fclose(fhandle)
}
else
show_error()
other_codes();

--
.~. Might, Courage, Vision. In Linux We Trust.
/ v \ http://www.linux-sxs.org
/( _ )\ Linux 2.4.22-xfs
^ ^ 5:00pm up 2 days 18:54 load average: 1.00 1.00 1.00

[Charles LaCour]

toylet wrote:

In most perl examples, it used this method to trap error:

open(INFILE, $fname) or die "Unable to open $fname";
process_file();
close(INFILE)
other_codes();

Now that if I don't want to die after the open so as to run
other_codes()? Could I test the value of file handle INFILE like what I
did with C?

fhandle=fopen(f name,"r")
if (fhandle > 0) {
process_file();
fclose(fhandle)
}
else
show_error()
other_codes();

Try something like this:
if ( -e $fname && -r $fname) {
open(INFILE, $fname) or show_error();
}
else {
die "Unable to open $fname";
}

The "-e" tests if the file exists and the "-r" tests if the file is
readable. If you want to see if it is writable use "-w". By testing
for the existence of the file and if you can read from or write to the
file first you can handle those situations gracefully and not have to
capture the error condition.

There is nothing special about the "or die". The "or" is just a logical
operator. Perl uses a short cut optimization of boolean statements.
the open statement returns a 1 if it suceeds and undefined if it fails.
So when the open statement succeeds it returns 1 and evaluating "1 or
anything" will alwayse be true so it will not do the "anything" on the
other hand of the open fails the returned undefined is treated as false
so the second part of the or needs to be evaluated so it could be any
statement or block of statement you want. Do not expect to get anything
of use out of the fhandle.

If you are going to continue writing scripts in perl I would suggest
getting a good book on it. My preferences are either from O'Reilly or
Wrox (if you can find them).

--
Thanks
Charles LaCour

[toylet]

Try something like this:
if ( -e $fname && -r $fname) {
open(INFILE, $fname) or show_error();
}
else {
die "Unable to open $fname";
}
statement or block of statement you want. Do not expect to get anything
of use out of the fhandle.
Too bad. I thought checking he file handle is the best appraoch. in
fact, many languages do that, like SQLCONNECT() in Foxpro, fopen() in
C/Clipper/Foxpro, ... It would be quite troublesome to work around that.
If you are going to continue writing scripts in perl I would suggest
getting a good book on it. My preferences are either from O'Reilly or
Wrox (if you can find them).

There are many websites hosting Perl books online. I use google.com to
find them. Thanks for the advice. What I really need is a job that
demands the use of perl, which is rather scarse in my city. Most of them
uses M$ tools.
--
.~. Might, Courage, Vision. In Linux We Trust.
/ v \ http://www.linux-sxs.org
/( _ )\ Linux 2.4.22-xfs
^ ^ 4:08pm up 5:41 1 user 1.03 1.01

[Joe Smith]

toylet wrote:

In most perl examples, it used this method to trap error:

open(INFILE, $fname) or die "Unable to open $fname";
process_file();
close(INFILE)
other_codes();

Now that if I don't want to die after the open so as to run
other_codes()? Could I test the value of file handle INFILE like what I
did with C?

In perl, open() does not return a file handle but it does return
a true/false value you can test.

if (open(INFILE, $fname)) {
process_file(IN FILE);
close(INFILE);
} else {
warn "Unable to read $fname: $!\n";
}
other_codes();

Be sure to include $! in the error message; it has strerror(errno) .
-Joe

[toylet]

> In perl, open() does not return a file handle but it does return

a true/false value you can test.
if (open(INFILE, $fname)) {
Be sure to include $! in the error message; it has strerror(errno) .
-Joe

that's what I should be going after. thanks.

--
.~. Might, Courage, Vision. In Linux We Trust.
/ v \ http://www.linux-sxs.org
/( _ )\ Linux 2.4.22-xfs
^ ^ 7:46pm up 9:19 1 user 1.00 0.94

[toylet]

> Be sure to include $! in the error message; it has strerror(errno) .

"$!" is a text message. can I get the errorno?
is it "$?" as in bash?

--
.~. Might, Courage, Vision. In Linux We Trust.
/ v \ http://www.linux-sxs.org
/( _ )\ Linux 2.4.22-xfs
^ ^ 7:48pm up 9:21 1 user 1.00 0.94

[Joe Smith]

toylet wrote:

Be sure to include $! in the error message; it has strerror(errno) .

"$!" is a text message. can I get the errorno?
is it "$?" as in bash?

$! = 28; # ENOSPC = 'No space left on device'
print "As a string, the last error was '$!'\n";
print "As a number, errno was ", $!+0, "\n";

That is, $! is magic. See also 'perldoc perlvar'.
-Joe

[toylet]

Thank you. Seems that perl requires the programms the know about context.

print "As a string, the last error was '$!'\n";
print "As a number, errno was ", $!+0, "\n";

--
.~. Might, Courage, Vision. In Linux We Trust.
/ v \ http://www.linux-sxs.org
/( _ )\ Linux 2.4.22-xfs
^ ^ 3:28pm up 15:48 1 user 1.02 1.00

[bob]

toylet wrote:

Thank you. Seems that perl requires the programms the know about context.

print "As a string, the last error was '$!'\n";
print "As a number, errno was ", $!+0, "\n";

Yes. but once you *do* know about it, it can be very convenient.

[toylet]

hmm... how do you force a variable into a certain context (could I also
call it "type casting")?

for integer, $i+0 or (int)$i.
for string, $i+""? or is it (string)$i?
for array
for hash

Yes. but once you *do* know about it, it can be very convenient.

--
.~. Might, Courage, Vision. In Linux We Trust.
/ v \ http://www.linux-sxs.org
/( _ )\ Linux 2.4.22-xfs
^ ^ 1:10pm up 2:19 1 user 1.41 1.33