Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!cs.utexas.edu!convex!usenet
From: tchrist@convex.COM (Tom Christiansen)
Newsgroups: comp.lang.perl
Subject: Re: new user findings
Message-ID: <1991May23.020207.12967@convex.com>
Date: 23 May 91 02:02:07 GMT
References: <13850@exodus.Eng.Sun.COM>
Sender: usenet@convex.com (news access account)
Reply-To: tchrist@convex.COM (Tom Christiansen)
Distribution: na
Organization: CONVEX Software Development, Richardson, TX
Lines: 144
Nntp-Posting-Host: pixel.convex.com

From the keyboard of matt@snave.Eng.Sun.COM (Matt Evans):
:=======================
: 1) caller command:
:=======================
:   PERL core dumps on the following 
:   code:
:
:
:#!/usr/local/bin/perl
:#---------------------------
:# start test (caller) main
:#---------------------------
:
:   $prog_dir = "./";
:   $prog_name = "not_here";
:
:
:   open (ERR_LOG,">./perr");
:
:   $proc_name = join ("",$prog_dir,$prog_name);

[just side note: this seems is a less obvious method (and more work) than]

	$proc_name = $proc_dir . $prog_name;
or
        $proc_name = "$proc_dir/$prog_name";

:   if (!( -e $conv_proc_name)) {

Warning: this variable was never defined.  stat()ing a null may count
as ".", but then again, maybe not.  On my system, it depends on whether
you compile in posix or traditional mode.

:    # after debugging the core file, it seems perl
:    # dies on the next line
:
:    ($pack,$file,$line,$sub_name) = caller (0);

Debugging the core file?  My, you *were* seriously curious!

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.)

:================================
: 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.

:================================
: 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.

Oh REALLY?  I can't repro this puppy.  Here's my C code:

    #include <stdio.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    main() {
	struct stat sb;
	if (fstat(fileno(stdin),&sb) < 0) {
	    perror("fstat");
	    exit(1);
	} 
	if ((sb.st_mode & S_IFMT) == S_IFCHR) {
	    fprintf(stderr, "stdin is a character device\n");
	} else {
	    fprintf(stderr, "stdin is NOT a character device\n");
	} 
    } 

and I invoke it from perl this way:

    require 'open2.pl';
    &open2('IN_HANDLE', 'OUT_HANDLE', "a.out");
    wait;
    exit $?;

On my system, it says that stdin is NOT a character device, which makes
sense, since it's reading from a pipe.  Does yours say otherwise?

However, I'd rather use isatty(fileno(stdin))) to figure out if it's 
a terminal device or not.  That way it won't be fooled by running
something like

    program < /dev/null


--tom
--
Tom Christiansen		tchrist@convex.com	convex!tchrist
		"So much mail, so little time."