Perl on Linux and AIX

[dcruncher4]

perl -v

This is perl, v5.8.0 built for i386-linux-thread-multi

here is a simple program (script name test.pl)

#! /usr/bin/perl -w

open(MSGF,"/dev/stdin") or die "ERROR\n" ;
while ( <MSGF> ) {
print $_ ;
}
close(MSGF);

I want to call it either of the two ways

test.pl < a_file
cat a_file | test.pl

On Solaris 5.10 both method works fine.

On Linux is 2.4.21-52.ELsmp #1 SMP i686 i686 i386 GNU/Linux

It works the first method.

But the second method fails. It dies with "ERROR".

On AIX 3 5 00CFADDC4C00 both methods are failing.


What can be the reason? I am a perl programmer and I don't know
much about Linux or AIX internals.

Is there a better way to do the task in Perl or do I have to write
OS specific code (I am open to that).

Thanks.

 

[Niel Lambrechts]

perl -v

This is perl, v5.8.0 built for i386-linux-thread-multi

here is a simple program (script name test.pl)

#! /usr/bin/perl -w

open(MSGF,"/dev/stdin") or die "ERROR\n" ;

I think you did it in a non-portable way.

# no need to call open()
while (<STDIN>) {
....
}

# or duplicate the FD
open(INCOPY, "<&STDIN" ) or die "Couldn't dup STDIN : $!";

# or alias the FD
open(INALIAS, "<&=STDIN") or die "Couldn't alias STDIN : $!";

cheers
Niel

 

[Uri Guttman]

d> open(MSGF,"/dev/stdin") or die "ERROR\n" ;

why are you explicitly opening that? stdin is already opened for your
program. that is your problem. that device is probably OS specific and
it has nothing to do with perl.

just use <> and it will read from your stdin just fine.

d> while ( <MSGF> ) {

while ( <> ) {

d> I want to call it either of the two ways

d> test.pl < a_file
d> cat a_file | test.pl

useless use of cat award.

d> On Solaris 5.10 both method works fine.
d> On Linux is 2.4.21-52.ELsmp #1 SMP i686 i686 i386 GNU/Linux
d> It works the first method.
d> But the second method fails. It dies with "ERROR".
d> On AIX 3 5 00CFADDC4C00 both methods are failing.

see if you even have /dev/stdin on those boxes. as i said, it makes no
sense to open it with that special device.

uri

 

[dcruncher4]

I think you did it in a non-portable way.

# no need to call open()
while (<STDIN>) {
...
}

You are right. What was I thinking. Actually this is a rewrite from
C to perl and I should used the C logic.

thanks.

 

[dcruncher4]

d> test.pl < a_file
d> cat a_file | test.pl

useless use of cat award.

ha ha.

Can't help it. This script will be called by other scripts and
my script has to be backward compatible with the C one.

 

[Robert M. Riches Jr.]

ha ha.

Can't help it. This script will be called by other scripts and
my script has to be backward compatible with the C one.

What is wrong with

test.pl < a_file

???

 

[Mike Andrews]

In comp.unix.aix,

What is wrong with

test.pl < a_file

<delurk>

If I'm writing scripts to read from stdin, I like to test them using
the same format that will be used in production.

I.e., if script PL is going to see output from program C, as in
C | PL > foo
then I include
something feeding PL through a pipe, e.g.,
cat C_output | PL
in the test harness
just so others can see how PL is to be run.

It's not a _useless_ use of cat, because the shape of the line shows
the neophyte who takes over when I'm sick or get hit by a truck just
how PL is used. There's a visual difference between
PL < C_output
and
cat C_output | PL
since
cat C_output
looks more like
C | PL > foo
than does
PL < C_output
..

IMHO, anyway.

</delurk>

 

[Uri Guttman]

d> test.pl < a_file
d> cat a_file | test.pl
d> ha ha.

d> Can't help it. This script will be called by other scripts and
d> my script has to be backward compatible with the C one.

huh?? that makes absolutely no sense. those two lines do the exact same
thing from the point of view of the perl script or any program in any
language that reads from stdin. you don't seem to have a grasp of how
stdio and redirection works on unix flavors.

uri

 

[Uri Guttman]

MA> It's not a _useless_ use of cat, because the shape of the line shows
MA> the neophyte who takes over when I'm sick or get hit by a truck just
MA> how PL is used. There's a visual difference between
MA> PL < C_output
MA> and
MA> cat C_output | PL
MA> since
MA> cat C_output
MA> looks more like
MA> C | PL > foo
MA> than does
MA> PL < C_output
MA> .

MA> IMHO, anyway.

useless use of a herd of cats award!

uri

 

[Uri Guttman]

d> You are right. What was I thinking. Actually this is a rewrite from
d> C to perl and I should used the C logic.

what does C logic have to do with opening an OS specific device like
/dev/stdin? all programs in all languages on unix flavors have stdin
open if forked from the shell (i will ignore those case where stdin is
closed by the parent). even in c you wouldn't need to open /dev/stdin
and if you did it should fail the same way on the same platforms as your
perl code. my point is again, it isn't a perl issue but a special device
on your platform issue and your not using the normal stdio given to you.

uri

 

[Gerard H. Pille]

huh?? that makes absolutely no sense. those two lines do the exact same
thing from the point of view of the perl script or any program in any
language that reads from stdin. you don't seem to have a grasp of how
stdio and redirection works on unix flavors.

uri

Your grasp is limited too, Uri.

There is quite a lot of difference. Maybe not "from the point of view
of the perl script", but try to see the complete picture, it will
help.

In the first case, you need an existing file. In the second, the
input may be generated without having to store it.

Any unix newbie would have seen that.

Gerard

 

[Tad J McClellan]

["Followup-To:" header set to comp.lang.perl.misc.]

d> test.pl < a_file
d> cat a_file | test.pl

It is not useless.

I think the OP was trying to say "my program must work in a pipeline".

(in which case, the answer is: write your program so that it reads
from standard input and writes to standard output, regardless of
which programming language you have chosen to use.)

d> Can't help it. This script will be called by other scripts and
d> my script has to be backward compatible with the C one.

huh?? that makes absolutely no sense.

The C program also worked in some sort of pipeline.

you don't seem to have a grasp of how
stdio and redirection works on unix flavors.

That's seems true enough.

 

[dcruncher4]

d> test.pl < a_file
d> cat a_file | test.pl

d> ha ha.

d> Can't help it. This script will be called by other scripts and
d> my script has to be backward compatible with the C one.

huh?? that makes absolutely no sense. those two lines do the exact same
thing from the point of view of the perl script or any program in any
language that reads from stdin. you don't seem to have a grasp of how
stdio and redirection works on unix flavors.

I am not the author of other scripts which are going to call my perl
script in either form. All I have to do is to ensure that both form works.

To my surprise I found that on Linux the first one worked and the second
one did not and that's why I posted here.

Thanks for your advise.

 

[Peter J. Holzer]

["Followup-To:" header set to comp.lang.perl.misc.]

What is wrong with

test.pl < a_file

???

For the user of test.pl? Nothing. That's the way they should use it if
the input is in a file.

But dcruncher4 isn't the user - he is the author. And as the author he
has to test all the ways his script will be used.

some_other_program | test.pl

is a way this script will be used someday. So he has to test whether it
works.

cat a_file | test.pl

does test that.

test.pl < a_file

doesn't (there are differences between a file and a pipe, most
importantly, a pipe isn't seekable).

hp

PS: dcruncher4's original program worked for me on linux (2.6.21).
Use of /dev/stdin is system-dependent, of course, but I see no
reason why it should work only for files, but not for pipes. Either
the system provides /dev/stdin, then it should work always, or it
doesn't, then it cannot work at all.