piping cmd output problem

[dimsol]

Hi

I have the following scenarion:

open(FILE, "some_cmd |") || die "some error message";
my $output = <FILE>;
close(FILE) || die "some error message";

The problem is that some_cmd failes (exit status 1) and prints error
message to STDOUT.

The return value of open() according to man pages is the pid of forked
process.
Now, the problem, how I can find out that some_cmd failed.

BR
Dima

 

[xhoster]

Hi

I have the following scenarion:

open(FILE, "some_cmd |") || die "some error message";
my $output = <FILE>;
close(FILE) || die "some error message";

The problem is that some_cmd failes (exit status 1) and prints error
message to STDOUT.

The return value of open() according to man pages is the pid of forked
process.
Now, the problem, how I can find out that some_cmd failed.

Since you say it prints the error message to its STDOUT, which has been
redirected into Perl's file handle FILE, why don't you just read the error
message from FILE? Alternatively, inspect $! and/or $? when either the
open or the close fails.

Xho

 

[Brian McCauley]

Hi

I have the following scenarion:

open(FILE, "some_cmd |") || die "some error message";
my $output = <FILE>;
close(FILE) || die "some error message";

The problem is that some_cmd failes (exit status 1) and prints error
message to STDOUT.

The return value of open() according to man pages is the pid of forked
process.
Now, the problem, how I can find out that some_cmd failed.

Think logically. You cannot get this answer from open() because that
would need information to travel backwards in time. So perhaps the
information is available from close().

perldoc -f close

 

[dimsol]

Parsing output of some_cmd is not good idea, since I can't filter all
error messages (I just don't know all possibilities and in the future
the author of some_cmd can add/modify them).

The safest and the simplest way is to know exit status of some_cmd.
$? returns zero.
close doesn't fail (since FILE is open file descriptor)

Dima

 

[Dima]

Parsing output of some_cmd is not good idea, since I can't filter all
error messages (I just don't know all possibilities and in the future
the author of some_cmd can add/modify them).

The safest and the simplest way is to know exit status of some_cmd.
$? returns zero.
close doesn't fail (since FILE is open file descriptor)

Dima

 

[xhoster]

Parsing output of some_cmd is not good idea, since I can't filter all
error messages (I just don't know all possibilities and in the future
the author of some_cmd can add/modify them).

So you are running a program that you have no control over and don't
understand what types of output it presents, yet you expect meaningful
results?

The safest and the simplest way is to know exit status of some_cmd.

Really? If the author of the program just makes up error messges
wily-nily, why do you expect the he is more conscientious with the exit
status?

$? returns zero.

Then maybe there isn't actually an error occurring.

close doesn't fail (since FILE is open file descriptor)

If the file handle came from a piped open "close" will addi-
tionally return false if one of the other system calls
involved fails or if the program exits with non-zero status.
(If the only problem was that the program exited non-zero $!
will be set to 0.) Closing a pipe also waits for the
process executing on the pipe to complete, in case you want
to look at the output of the pipe afterwards, and implicitly
puts the exit status value of that command into $?.

Xho

 

[Joe Smith]

close doesn't fail (since FILE is open file descriptor)

Just because FILE is an open file descriptor does not mean
that close(FILE) will never fail. You need to check the
docs on close() - it shows how to do what you want.
-Joe