query status of STDIN

[Andrei Alexandrescu (See Website For Email)]

Hello,


Here's a tricky one. I have a perl script that most of the time is
invoked like this:

$ some_command | my_perl_script

Now, inside my_perl_script, when reading STDIN through end-of-file, I
want to look at the exit status of the "upstream" command, that is,
some_command. If that command has a nonzero exit status, I deem the
input as incomplete.

How can I do that in perl? Is there a way of figuring out the exist
status of STDIN, in case that came as a pipe?


Thanks,

Andrei

 

[Andrei Alexandrescu (See Website For Email)]

How can I do that in perl? Is there a way of figuring out the exist
status of STDIN, in case that came as a pipe?

s/exist/exit/

Andrei

 

[Joe Smith]

STDIN does not have an exit value.

You'll need to create the pipe yourself, and check the value
returned from close().

linux% perl -e 'open P,shift()."|" or die; while(<P>){print;} $e=close
P; print "Pipe close = ",0+$e,"\n"' false
Pipe close = 0
linux% perl -e 'open P,shift()."|" or die; while(<P>){print;} $e=close
P; print "Pipe close = ",0+$e,"\n"' true
Pipe close = 1
linux% perl -e 'open P,shift()."|" or die; while(<P>){print;} $e=close
P; print "Pipe close = ",0+$e,"\n"' date
Sun Nov 20 20:54:51 PST 2005
Pipe close = 1

The value of close(P) is true if the process feeding the pipe exited
without an error code.
-Joe

 

[brianr]

Hello,


Here's a tricky one. I have a perl script that most of the time is
invoked like this:

$ some_command | my_perl_script

Now, inside my_perl_script, when reading STDIN through end-of-file, I
want to look at the exit status of the "upstream" command, that is,
some_command. If that command has a nonzero exit status, I deem the
input as incomplete.

How can I do that in perl? Is there a way of figuring out the exist
status of STDIN, in case that came as a pipe?

The exit status of a program is generally only available to its
parent, which in this case would have to be my_perl_script. Your Perl
script could execute some_command itself, and replace its STDIN with
the piped output. For example:

----------------------------------------------------------------------
use strict;
use warnings;

use Getopt::Std;

my %opts;
getopts("c:", \%opts) or die "Bad switch\n";

if (defined $opts{c}) {
open STDIN, "$opts{c} |"
or die "Failed to start command '$opts{c}': $!\n";
}

while (<>) {
print "IN: $_";
}

if (defined $opts{c}) {
close STDIN;
print "Incomplete\n" if $?;
}
----------------------------------------------------------------------

This could then be executed as

$ my_perl_script -c "some_command arg1 arg2"

For more info see:

perldoc perlopentut
perldoc -f open
perldoc perlvar

HTH

 

[Tad McClellan]

Actually, it does.

No it doesn't.

An "exit value" has nothing to do with input/output nor filesystems.

An "exit value" is produced by a "process".

The _program_ that is writing to perl's STDIN has an "exit value",
that is, the program on the left of the pipe.

This exit value is an "end of file" (eof) signal.

Special characters in an input stream are neither an "exit value"
nor a "signal".

 

[Mark Clements]

Tad McClellan wrote:

"Left" of a pipe? Your left or my left? What is on the "right"
of the pipe? If you were so ignorantly arrogant, you might
become knowledgeable enough to employ correct terms,
such as input, output, read and write.

You know full-well what he means. I hope you are enjoying your game,
whatever it is.

my $pipe_h;
open $pipe_h, "/bin/ls |" or die $!;
while(my $line = <$pipe_h>){
print $line;
}

Here, /bin/ls is to the left of the pipe. It is clear enough from the
context in the post previous to yours that "pipe" refers to "pipe symbol".

An eof signal is not a special character nor special characters.
This is a signal a data handling process is finished, with success.
This signal is and can be generated by many methods, including
perl core and including your own code.

"signal", at least as far as perl is concerned, means something very
specific: it means a traditional unix signal that a process receives
from another process (or itself) that it can generally act upon or
ignore, for example, HUP and INT. It is a basic building-block of
interprocess communication, though according to perldoc perlwin32 "may
not behave as on unix platforms" on Windows. Check out

perldoc perlipc

eof is a value returned from a function that reads from a filehandle to
denote the end of file or an error condition.

There is no mention of signals in

perldoc -f eof

Mark

 

[Tassilo v. Parseval]

Also sprach Purl Gurl:

Mark Clements wrote:

Both Perl Developers and Perl Porters refer to eof as a signal. This
is documented "all over the place" especially in Perl 6 documentation
and developer discussions.

Let's test that claim:

ethan@ethan:~/Projects/APC/perl-current$ grep -r -i 'eof signal' *
ethan@ethan:~/Projects/APC/perl-current$

Your "especially in Perl 6 documentation" implies that it should be
mentioned in the perl5 source tree as well, somewhere. But not
surprisingly, it isn't.

Now what are you to do? Troll and insult Perl Developers and Porters?

And you're just an ordinary pathetic liar.

Will you tell them how wrong they are?

Given the above empty grep, they are right: There is no such thing as an
eof signal.

There are thousands of pieces of documentation, thousands of manuals,
thousands of references, thousands of people, all of which or whom, refer
to eof as a signal.

There is no such thing as an eof signal.

Correcting those written materials and experts, should keep you boys
busy for decades to come.

Those written materials that don't exist as we've seen above.

Best get busy because there is equal amounts of sources which refer
to eof as "flag," "marker," "exit code," "exit status" and other terms.

Eof flags and markers are ok, eof exit codes and eof exit status don't
exist.

Filehandles do have and display exit codes despite your contrary rants.

Filehandles don't exit whereby they cannot have an exit code.

My game is major league, with an intellectual bullet.

Your game is major league trolling, with an intellect roughly as big as
a cherry pit.

Tassilo

 

[Dave Weaver]

An eof signal is not a special character nor special characters.
This is a signal a data handling process is finished, with success.

Really?

So how does a data handling process signal it is finished without
successs? By leaving the file open?

 

[Mark Clements]

Periodically, I leave here. Sometimes for months, sometimes
for over a year. Recently I returned. Within two hours of my first
post, at night, many of you boys were posting both ignorant
and mean spirited troll articles directed at me. Archives well
evidence those events. Literally in a matter of minutes, you
boys were posting ignorantly laughable troll articles upon
my first few returning posts here.

It is very simple: you continue to post demonstrably incorrect
information and people will continue to correct you. The fact that you
take such gleeful offence at being corrected is just a bonus.

Recently a bunch of you ignorant trolls started ranting about
URL decoding and my posted method. A few days later, a
Perl FAQ appears displaying the same code method I use,
a participant or two discussed methods same as mine, and
the Perl FAQ maintainer agreed to add code much like mine.
They were not trolled.

You (predictably) miss the point. Several possible solutions were
posted, one of which was yours. You then posted timing data in an
attempt to prove that because your submission executed faster it was
superior. Issue was taken with your misappraisal (again) of the aims of
programming, not with your solution per se.

No. That is a read process, not a "left of the pipe" process. I suggested you
boys learn to use correct terminology, input, output, read, write and such,
and here you are defending use of incorrect terminology; street slang.

In effect, ls is writing to the pipe, not reading. How is it a "read
process"?

Mark

 

[Tad McClellan]

A process cannot "finish" without success.

A process most certainly can fail to perform its designated task.

Failure and success are mutually exclusive.

I have suggested many times to research and read to learn.

Yeah, but nobody listens to you for some reason.

 

[Andrei Alexandrescu (See Website For Email)]

Really?

So how does a data handling process signal it is finished without
successs? By leaving the file open?

Without desiring to engage in the flame war that ensued, let me
factually say that indeed eof is irrelevant to my question because it
doesn't indicate the exit code of the process that might have created
the stream.

Thanks to the people who posted relevant answers.


Andrei

 

[Andrei Alexandrescu (See Website For Email)]

Andrei Alexandrescu wrote:




There is nothing "factually" about your comments.

Your statements are both incorrect and do not comply with
your original article. You have changed your parameters which
is a strong indicator of a troll.

This might be a misunderstanding. I haven't changed anything. I've just
done my best to explain the problem I was facing, and then I confirmed
that eof is not the answer to that problem. Most people on this group
understood my question. I won't spend any more time focusing on whether
my words can be interpreted in ways that could make your initial answer
plausible. Again, most (actually, all other) posters understood what I
was asking for, and gave salient answers.

You originally wrote,

"Now, inside my_perl_script, when reading STDIN through end-of-file, I
want to look at the exit status of the "upstream" command, that is,
some_command. If that command has a nonzero exit status, I deem the
input as incomplete.

How can I do that in perl? Is there a way of figuring out the exist
status of STDIN, in case that came as a pipe?"

You indicate "end-of-file," "upstream command," and "input as incomplete."

You specifically ask for the "exist" status of STDIN.

All of those conditions are ascertained by an eof signal.

(I corrected in a subsequent post "exist" with "exit".)

I don't understand how the eof signal can tell me what was the exit
status of the process that might have engendered the STDIN stream. If
you could post me some code, I'd be grateful.

So, to illustrate my question with an example in an attempt to clear any
possible misunderstandings:

$ (echo "blah"; exit 0) | my_perl_script
$ (echo "blah"; exit 1) | my_perl_script

I want my_perl_script to be able to detect that exit code, even though
their STDIN contents is the same. My current understanding is that that
is not possible without additional scaffolding.

(By the way, the "pipestatus" environment variable makes that
information available on some shells, but only for the last foreground
pipeline.)

Your current comments directly contradict your orignal article,
and contain inflammatory comments, some of which, have
been snipped.

Well isn't there at least a possibility that your current understanding
of my problem directly contradicts your understanding of my original
article?

Rather clear you are a troll.

You may want to plonk me and disregard all of my posts.


Andrei