Sad experience with redirecting to /dev/null

[Mike Hunter]

I just got through with a very painful debugging expierience:

....
system("iperf -s -D >/dev/null");
....
my $var = <STDIN>;
print "major screwage!" unless defined $var;

It prints "major screwage!"...*sigh*. If I take out the ">/dev/null", it
works fine.

I'm using FreeBSD 5.2.1-release with perl 5.6.1.

Please choose:

A) This is expected unix behavior; go back to windows, fungus!

B) This is a known bug

C) This is triggering a known bug in something else

D) You screwed up somewhere else

E) Write to Lary Wall immediately!

E) All of the above

 

[Mike Hunter]

I just got through with a very painful debugging expierience:

...
system("iperf -s -D >/dev/null");
...
my $var = <STDIN>;
print "major screwage!" unless defined $var;

It prints "major screwage!"...*sigh*. If I take out the ">/dev/null", it
works fine.

I should have also said I tried switching to

fork || exec "iperf -s -D >/dev/null"

with the same results.

 

[Tony Curtis]

I just got through with a very painful debugging
expierience: ... system("iperf -s -D >/dev/null"); ... my
$var = <STDIN>; print "major screwage!" unless defined $var;

It prints "major screwage!"...*sigh*. If I take out the
">/dev/null", it works fine.

I'm using FreeBSD 5.2.1-release with perl 5.6.1.

Please choose:

A) This is expected unix behavior; go back to windows,
fungus!

Correct (well, the first part anyway . You are redirecting
all standard output from the command into a black hole. You
are then reading from a stdin that is completely unrelated to
the forked command.

I suspect you want to pipe the system() command instead:

open($fh, 'iperf... |') or die blah blah;

... read from $fh ...

close($fh) or die blah blah;


hth
t

 

[Joe Smith]

I just got through with a very painful debugging expierience:

...
system("iperf -s -D >/dev/null");
...
my $var = <STDIN>;
print "major screwage!" unless defined $var;

It prints "major screwage!"...*sigh*. If I take out the ">/dev/null", it
works fine.

The system() and exec() functions are sensitive to shell metacharacters.
system("iperf -s -D >/dev/null");
is treated like
system("/bin/sh", "-c", "iperf -s -D >/dev/null");
but the one without ">" is treated like
system("iperf", "-s", "-D");

Try debugging it from the command line:
csh% sh -c 'iperf -s -D >/dev/null'
to see if behavior is different when /bin/sh is involved.

-Joe

 

[Mike Hunter]

Correct (well, the first part anyway . You are redirecting
all standard output from the command into a black hole. You
are then reading from a stdin that is completely unrelated to
the forked command.

I *want* to be reading STDIN from the perl script, not iperf. Iperf is a
daemon that I want to be launched, and I'd rather not see any of it's
startup output. system should execute the command and return to the perl
script with STDIN intact, but I'm accusing it of breaking my connection
to STDIN for some unexplained reason.

Mike

 

[Tony Curtis]

I *want* to be reading STDIN from the perl script, not
iperf. Iperf is a daemon that I want to be launched, and
I'd rather not see any of it's startup output. system
should execute the command and return to the perl script
with STDIN intact, but I'm accusing it of breaking my
connection to STDIN for some unexplained reason.

Ah, well that's a different elephant altogether isn't it?

Try tracing the binary with/without stdout redirected
(truss/strace or whatver it is on FreeBSD) and see if there's
a difference in stdout behaviour.

hth
t

 

[Gary E. Ansok]

I *want* to be reading STDIN from the perl script, not iperf. Iperf is a
daemon that I want to be launched, and I'd rather not see any of it's
startup output. system should execute the command and return to the perl
script with STDIN intact, but I'm accusing it of breaking my connection
to STDIN for some unexplained reason.

So redirect iperf's stdin as well, that way it shouldn't touch yours:

system("iperf -s -D </dev/null >/dev/null");

Gary Ansok

 

[Mike Hunter]

So redirect iperf's stdin as well, that way it shouldn't touch yours:

system("iperf -s -D </dev/null >/dev/null");

Good advice. But:

1. I shouldn't need to do that...right? A command run from system if fork'd
off and should have its own file handles.

2. Doing this provided the same results:
"/usr/local/bin/iperf -s </dev/null >/dev/null &"

I didn't use -D, but -D seems to be causing me other problems (the remote
clients hang).

I am pretty convinced this is a iperf problem, but I still question what iperf
could be doing that would be allowed to screw with my <STDIN>....

Thanks.

Mike

 

[Mike Hunter]

Ah, well that's a different elephant altogether isn't it?

Try tracing the binary with/without stdout redirected
(truss/strace or whatver it is on FreeBSD) and see if there's
a difference in stdout behaviour.

Thanks...unfortunately I find myself not sufficently cool to follow ktrace
through iperf's fork...

Mike

 

[Joe Smith]

Good advice. But:

1. I shouldn't need to do that...right? A command run from system if fork'd
off and should have its own file handles.

You DO have to do that. A command run from system shares STDIN, STDOUT and
STDERR. The higher numbered file handles are not shared but 0, 1 and 2 are.

I would use
system("iperf -s -D </dev/null >>/var/log/iperf.log 2>&1 &");

-Joe