Strange error message: "ng [filename.php]

[snorkytheweasel]

Webuilder 2010
xp-sp3

See code below.

In Webuilder, if I comment out the function and the loop, the syntax check shows "No syntax errors were found."

If I enable either or both - function and loop - Webuilder syntax check throws "Ng panda.php"

I'm running the script in a dos window. With or without the function and/or loop it runs without blowing up, although it doesn't produce the complete "results" file that I need.

• If the directory does not have the "results" file, the script creates a 0 length "results" file with the correct name.
• If the "results" file exists, the script does not overwrite or delete the existing file. It also leaves it where length=0.
• If I delete the "results" file, and run the script, all that it does is to create a new 0-length file.

Given that enabling the function and/or loop generates the "Ng panda.php" error, it appears that the problem is in function(reportit)

Question #1: What is "Ng panda.php"?
Question #2: Will understanding that error message help me debug the script?
Question #3: Can anyone out there tell me what's wrong? Is it the code? Is there a more fundamental error, e.g. 'you can't run that kind of script in a dos window' or some such mistake.

Code: Select all

<?php   /* -- compare nslookup for hostname & ip address -- */

//	declare vars
	
	$dir		= ".";		                    //	folder for input and results files
	$thisday	= date(Ymd);                    //  date used in file names ex: 20100316

	$filein		= $thisday . "-panda.txt";	    //  input file
	$fileout	= $thisday . "-results.txt"; 	//  results file
	$handlei	= fopen($filein,  'r');         //  open input file read-only

	$texta		= " - computers without Panda\n";   //  part of header line in results page
    $textb      = $thisday.$texta;

/* ---- sanity check
print $filein  . "\n";
print $fileout . "\n";
print $textb . "\n";
*/

fopen($fileout, 'w');                           //  open the output file for write
fwrite($fileout, $textb);                       //  print header line at top of results page
                                                //  leave results page open for more writes

/* ---- example of vars in function below

    $data	=	OHE-CL30,10.11.1.59
	$z		=	19                      //  count of chars in entire line
	$b		=	8                       //  location of comma
    $a		=	0,7     "OHE-CL30"      //  1st substring in $data
	$c		=	9,18    "10.11.1.59"    //  2nd substring in $data
*/


function(reportit)
	{
	//	get values for vars

		fopen($filein,'r');                 //  open the input file

		$data=fgets($handlei,60);           //  the string being read
		$z = strlen($data);                 //  how many chars in entire line
		$b = strpos($data,",");             //  find the comma
		$a = substr($data,0,($b-1));	    //  hostname
		$c = substr($data,($b+1),($z - 1))	//  ip address

	//	compare ip & host name

		print " \n ----------------- \n";
		shell_exec(nslookup $a >> $fileout);
		shell_exec(nslookup $c >> $fileout);
		print " \n ----------------- \n";

	}



while (!feof($handlei))
{
	reportit()		// do it;
}



close ($filein);
close ($fileout);

?>

[snorkytheweasel]

WeBuilder 2010
xp-sp3

When I looked at my code this morning, I wondered what moron wrote it I re-wrote the code (after getting some much-needed sleep). So we can lay the blame for that part of the fiasco at my feet (and weary brain). Starting with a blank screen and blank mind got me code that now works mostly as intended.

However....

When I did syntax checks along the way, here's what I found:

• If my code was correct, the syntax checker said "no syntax errors found." That's what I expect to see.
• ANY mistakes caused WB to throw that obscure error Ng [filename.php] AND to move the cursor to position 0, line 0. What I expect to see is the standard debugging response in which
  • the problem is described
  • the line number is cited
  • the cursor moves to near the location of the error

All prior versions of WB and Rapid PHP helped me to debug that way. WB 2010's generic "one size fits all, you guess where and what the problem is" response is useless. In fact, it's a show-stopper. I may as well go back to the previous version of WB.

What happened between versions 2009 and 2010?

FWIW, here is the new code:

Code: Select all

<?php   /* -- compare nslookup for hostname & ip address from an error log -- */

// -----begin vars -----------

        $dir		= ".";		                    //	folder for input and results files
        $thisDay	= date("Ymd");                    //  date used in file names ex: 20100316

        $fileIn		= $thisDay . "-panda.txt";	    //  input file
        $fileOut	= $thisDay . "-results.txt"; 	//  results file

        $handleI	= fopen($fileIn,  'r');         //  open input file read-only

        $textA		= " - computers without Panda\n";   //  part of header line in results page
        $textB      = $thisDay.$textA;

// -----end vars ------------

// ----- begin functions -------------

        function sanityCheck1()
        {
          global $thisDay;
          global $fileIn;
          global $fileOut;
          global $textB;
          print  $thisDay  . "\n";
          print  $fileIn   . "\n";
          print  $fileOut  . "\n";
          print "Headline  will be " . $textB    . "\n";
        }

      function openFileOut()
      {
        global $fileOut;
        global $textB;
        fopen($fileOut, 'w');                           //  open the output file for write
        fwrite($fileOut, $textB);                       //  print header line at top of results page
      }                                                //  leave results page open for more writes

      function openFileIn()
      {
        global $fileIn;
        fopen($fileIn,'r');                 //  open the input file
      }

  /* --- example of values in function getValues()

    $data	=	OHE-CL30,10.11.1.59
  	$z		=	19                      //  count of chars in entire line
  	$b		=	8                       //  location of comma
    $a		=	0,7     "OHE-CL30"      //  1st substring in $data
  	$c		=	9,18    "10.11.1.59"    //  2nd substring in $data

  --- end example -------------- */

      function getValues()
      {
        global $handleI;
        $data=fgets($handleI,60);           //  the string being read
        $z = strlen($data);                 //  how many chars in entire line
        $a = substr($data,0,($b-1));	    //  hostname
        $b = strpos($data,",");             //  find the comma
        $c = substr($data,($b+1),($z - 1));	//  ip address
      }

      function lookUps()	//	compare ip & host name
      {
        global $a;
        global $c;
//        $aa = shell_exec("nslookup") $a;  /* --- syntax of shell_exec() is not correct yet --- /*
//        $cc = shell_exec("nslookup") $c;   /* --- syntax of shell_exec()is not correct yet --- /*
      }

      function loop()
      {
        global $handleI;
        while (!feof($handleI))
        {
          getValues();
          lookUps();
        }
      }

      function finis()
        {
          global $fileIn;
          global $fileOut;
          close ($fileIn);
          close ($fileOut);
          exit();
        }

// ----- end functions -------------

sanityCheck1();  // optional - for debugging
openFileOut();
openFileIn();
loop();
finis();

?>

[RobertJ]

You need to configure your php.ini with "display_errors = On"

[snorkytheweasel]

That must be the default setting, because it was already ="On" and I haven't edited the file.

[Karlis]

Somehow you are not getting the results everybody else is getting and it is not because of version 2010.

I have never sene this error message and have no idea how to get it. Any pointers?

[snorkytheweasel]

The easiest way to generate the error is to write some php code and use the preview feature or do a php syntax check.

Neither WeBuilder nor other php tools had this problem before the WeBuilder upgrade.

The fix was to install php.exe downloaded from your site. That version of PHP works with WeBuilder AND other the PHP tools that I use.

My only suggestion is to note somewhere that strange errors involving PHP might be solved by getting PHP.exe from your web site.

Let's declare victory over this obscure glitch!

We're #1! We're #1!

[Karlis]

Most likely the problem happened because the developers of PHP are inconsistent in every possible way. Each new version of PHP works differently and it is often very difficult to follow these changes. We will try to look into this.