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(fname,"r")
if (fhandle > 0) {
process_file();
fclose(fhandle)
}
else
show_error()
other_codes();

 

[Charles LaCour]

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(fname,"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).

 

[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.

 

[Joe Smith]

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(INFILE);
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.

 

[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?

 

[Joe Smith]

"$!" 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.

 

[bob]

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

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

 

[Ben Morrow]

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

You almost never need to. About the time string/number matters is with
magic values like $!; other than that, scalar context can be forced with
scalar() or unary + and list context with parentheses ().

for integer, $i+0 or (int)$i.

yes no, though int($i) will give you int rather than
float

for string, $i+""? or is it (string)$i?

$i.'' or "$i" no

for array
for hash

eh what? Please explain what you expect, e.g., (hash)$i to achieve?

Ben

 

[toylet]

for array

eh what? Please explain what you expect, e.g., (hash)$i to achieve?

Just asking for a general method of forcing context.

 

[Anno Siegel]

You almost never need to. About the time string/number matters is with
magic values like $!; other than that, scalar context can be forced with
scalar() or unary + and list context with parentheses ().

Parentheses only provide list context on the left side of an assignment
(anywhere else?). Watch this:

sub wanta { print wantarray ? "array\n" : "scalar\n" }

$x = wanta;
( $x) = wanta;
$x = ( wanta);
( $x) = ( wanta);

The parentheses on the right side don't seem to do anything.

I can't meaningfully say much about the difference between unary +
and scalar(), except that there is one. Vaguely, "+" can change parsing,
scalar() can't.

[...]

And if you wanna make sense / Whatcha looking at me for? (Fiona Apple)

Can't say I understand that sig of your's, but I like it

Anno

 

[Anno Siegel]

You almost never need to. About the time string/number matters is with
magic values like $!; other than that, scalar context can be forced with
scalar() or unary + and list context with parentheses ().

Parentheses only provide list context on the left side of an assignment
(anywhere else?). Watch this:

sub wanta { print wantarray ? "array\n" : "scalar\n" }

$x = wanta;
( $x) = wanta;
$x = ( wanta);
( $x) = ( wanta);

The parentheses on the right side don't seem to do anything.

I can't meaningfully say much about the difference between unary +
and scalar(), except that there is one. Vaguely, "+" can change parsing,
scalar() can't.

[...]

And if you wanna make sense / Whatcha looking at me for? (Fiona Apple)

Can't say I understand that sig of your's, but I like it

Anno

 

[Joe Smith]

Just asking for a general method of forcing context.

($a,$b) = foo(); # List context
@array = foo(); # List context
%hash = foo(); # List context
foo(); # Null context
$var = foo(); # Scalar context
$var = +foo(); # Numeric scalar context
$var = foo().""; # String scalar context
if (foo()) {}; # Boolean scalar context

-Joe

 

[Tassilo v. Parseval]

[ F'up set to clpm;
comp.lang.perl doesn't exist ]

Also sprach Joe Smith:

toylet wrote:

($a,$b) = foo(); # List context
@array = foo(); # List context
%hash = foo(); # List context
foo(); # Null context
$var = foo(); # Scalar context
$var = +foo(); # Numeric scalar context

Nope. This does not force numeric context. This does:

$var = foo() + 0;

Or this:

$var = foo() * 1;

Any numeric operator in conjunction with the neutral element with
respect to the used operator can be used to enforce numeric context.

Tassilo