Newsgroups: comp.lang.perl
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.jpl.nasa.gov (Larry Wall)
Subject: Re: new user findings
Message-ID: <1991May23.054049.5849@jpl-devvax.jpl.nasa.gov>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
References: <13850@exodus.Eng.Sun.COM> <1991May23.020207.12967@convex.com>
Distribution: na
Date: Thu, 23 May 1991 05:40:49 GMT

In article <1991May23.020207.12967@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
: From the keyboard of matt@snave.Eng.Sun.COM (Matt Evans):
: :=======================
: : 1) caller command:
: :=======================
: :   PERL core dumps on the following 
: :   code:
: :    ($pack,$file,$line,$sub_name) = caller (0);
: 
: I get the same behavior.  Using just caller with no args, or
: caller(1), makes it work.  Sounds like a bug for Larry (or
: other ambitious volunteers.)

I fixed that one several weeks ago.  As a workaround, run your script under
the debugger.

: :================================
: : 2) numeric & string equalities
: :================================
: :
: : In reading the camel book, it seems there should be no problem
: : in comparing strings and numbers, However the behavior of the 
: : following perl code seems inconsistent:
: :
: :
: :#!/asdf/bin/perl
: :
: : $x = "test";
: : if ($x == 0) {
: :    print "x is equal to 0\n";
: : }
: : if ($x eq "test") {
: :    print "x is equal to the str \"test\"\n";
: : }
: :
: : ------------------------------------------
: :
: : output:
: :
: : x is equal to 0
: : x is equal to the str "test"
: :
: :
: : Question: Why does $x compare equally to numeric 0? Is this
: :	   correct behavior?
: 
: $x evaluates to numeric 0, all right.  That's because *numerically*
: the string "test" is 0, as are nearly all other strings, except
: things like "-1", "1e8", etc.  awk behaves the same way.

"test" seems more equal to 0 than to any other number...

: :================================
: : 3) tom christiansen's open2.pl
: :================================
: :
: : This is more of a question and a FYI. I was using the open2.pl
: : routine to fire off a process from perl. The routine works
: : like a champ, but it has an interesting side effect. This side
: : effect actually occurs in the spawned process. The spawned
: : process I was running does an fstat on STDIN to tell if it
: : has been started interactively from a terminal  or if it
: : has been spawned using pipes. (this C program does many things
: : differently based on whether it is started from pipes or
: : a character device).
: :
: :   C code snipit:
: :
: :     if ((sbuf.st_mode & S_IFMT) == S_IFCHR) {
: :        input_term = TRUE;
: :     }
: :     else {
: :           input_term = FALSE;
: :     }
: :
: : well, if the process is started from perl using open2.pl the
: : process thinks it was started from a terminal i.e from above
: : the var input_term is assigned to TRUE.

In general, what an OS puts into the stat structure for a pipe is
kinda hit or miss.  You may have some funny remnants of however dup2()
is implemented.  I wouldn't trust st_mode too far on pipes.  Maybe
you should check some of the other fields first.  If your pipes are
implemented as anonymous FIFO's you should be able to tell from st_dev
and st_ino, I think, or maybe st_nlink.  Happy hunting.

Larry
