Php syntax checking reports error that is not an error

danallen · 2017-12-29 04:02:47 UTC

php syntax checking reporting syntax error that does not appear to be an error. Here is a picture of what the error looks like in Atom.

Here is the code.

	<?php
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);


if(!isset($GLOBALS['trace'])):
	$GLOBALS['trace']=false;
endif;
if ($GLOBALS['trace']):
	?>
	<html>
	<head>
		<style>
			.green{color:rgb(0,150,0);}
			.red{color:rgb(210,0,0);}
		</style>
	</head>
	<body>
<?
endif;

I am guessing it is an error that php does not know is an error of its own rules. I just want the error report to go away until l can see something go wrong besides the error checker.

Running that php throws no errors. Humm, my server is php 5.6. Maybe that php is in error in php 7.

Songworks · 2017-12-29 04:25:02 UTC

The setting for the shorthand php tag <? may not be on in your system. Either set short_open_tag in your php.ini to allow it or use <?php at all times. The latter is encouraged as it will work anywhere regardless of the ini setting.

danallen · 2017-12-30 09:17:29 UTC

Songworks, thank you for taking a look at my problem and suggesting a direction for solving it. I don’t understand why and how but in the course of pursuing your suggestion the red dot has disappeared. There is something about this I need to ask you about, but I need to provide background first.

First, progress toward killing the red dot in php script. I have not killed it yet, but I did find a way to make it react. The two pictures below show what I found, including a surprising result, where adding php to a short tag caused the red dot to APPEAR not DISAPPEAR.

This is where I started.

And this is the surprising result:

**

Much Bigger Question**

This is extremely important to keep my brain from melting and running out of my ears.

This script runs on my php installation without reporting any error. The php.ini file is modified from the default, allowing short tags. Here is the setting in the php.ini file

and here is the status of that directive reported by your good friend (she speaks very well of you), and mine, phpinfo()

Then, invoking the No Horse is Too Dead to Beat Doctrine, I put this check into top of the script where Atom is reporting a syntax error.

And here is the output from that check:

Here is the kick: all this about the php.ini file is red herring, absolutely unrelated to this problem. PHP is not reporting any errors. Only ATOM is reporting a syntax error.

When php runs on my rig, this is how an observant programmer can spot a syntax error:

Atom says there is a syntax error:

PHP Disagrees

But Wait! There is More!
For kicks, I am going to the php.ini file and turning short_open_tag OFF.

restarting apache, since php is running in apache in this situation.

Check with our buddy, phpinfo():

And sure enough, that kills my web app:

But still is unrelated to my problem. ATOM is not reporting an error related to short tags not being allowed.

Now here is my question for you. Is there any way for Atom to know whether short tags are allowed in this php installation? I don’t think Atom knows one way or the other.

So, there are all my great (not) theories of the day…
and in fact, the red dot got lost over the course of this journey. I am looking forward to learning how I am misunderstanding this and going about this wrong.

Songworks · 2017-12-30 15:33:15 UTC

No, Atom knows nothing about this. The entire linting is done by a ‘language package’, in your case linter-php, which provides any errors to linter and Atom then is merely a tool to display the errors found (crudely explained though).
And yes, the red dot only means: “Linting failed on this code/file and it’s approximately around this line.”

Now, two more points:

Internally linter-php executes php -l for linting, and here might lie the original problem: This commandline executable of php and the apache implementation use two different php.ini files. You can find out which one the cli uses by executing php --ini and then see if that ini file has short_open_tag set to Off or On.
The new linter error in file 000-dansoft-core.php on line 1005: What exactly is the error message there?
I’m curious about it, especially since the endwhile is underlined red, which indicates the linter knows exactly what’s wrong there, rather then with your initial problem.

danallen · 2018-01-01 06:02:31 UTC

I appreciate the explanation on how the red dot is generated.

The scripts I am working won’t run from the command line, because they rely on $_SERVER variables for the the foundation of the application architecture. Without those server variables, these scripts bomb all over the place.

At this point, what I would like to do is remove linter-php from my system or disable it. I have formed the impression that is not a practical option. Is it possible to tell the linter to use a different php.ini file? I don’t want to configure the command-line php on my pc to match the web-based php on my server.

I think I should say again, I do not run php my local system. I run it only on remote servers. Atom cannot see the command line php on any of those remote servers, so its attempts to check my code are futile. The remote servers are running as virtual linux instances with VMWare, so the remote servers are actually on my office machine, but they are seen and operate as remote instances across a network.

The only thing I know I need to run that might be depending on the linter is matching opening and closing html tags (not auto completing them, just show the match for any html opening or closing tag.) For me, that is helpful feature that saves me a lot of time and aggravation. I can see that makes no sense to suggest this feature would be tied to the php linter, because matching html opening and closing tag would not require anything from php, or maybe it does when php and html are intermingled. I am very confused in the linter and bracket matching functionality on Atom, but what you explained cleared up a the php systax recognition problem, I really appreciate that. Thank you.

As for the problem on line 1005, I am sure it is related to the $_SERVER variables in that script. The red dot is gone now. I hope you will not be frustrated for your question to be left open.

Songworks · 2018-01-01 19:28:59 UTC

The php-linter package has a setting for which php executable it should use (default just php) and php in turn also has an option -c <path>|<file> to tell it where to locate/find a php.ini.
So if you can make the remote servers ini available locally you could use it for the setting, i.e.:
php -c /path/to/remote/php.ini

However, take note that the versions of your local php and the remote one aren’t too far apart. Preferably should be the same to avoid further trouble from breaking changes and whatnot.
You could theoretically also set the php-linter setting to execute the remote php (through ssh perhaps?) but that’s just a quick idea and I got no proof of concept if it is possible at all.

Also it is possible to set additional variables to $_SERVER on cli, but any practicality of it depends on how many variables your application requires.

No worries.

danallen · 2018-01-02 09:38:59 UTC

That sounds perfect and I setting it up right now

danallen · 2018-01-02 11:37:40 UTC

I took another look, found the red dot still is sticking around, apparently seeking to mate with the endwhile. I took the function containing the endwhile, gave it its own file, put long tags on all the php opens. and the red dot still is there.

I ran php-l filename and put the response in the upper right part of the picture.

danallen · 2018-01-02 14:41:56 UTC

Here is another one php-linter is choking on, while php runs it without any notices, errors, warnings. The script is entered into this post beneath the image showing the linter’s red dot.

<?php
$sql="	select distinct
ul.nUserLevel_ID,
ul.alog_skey as ul_alog_skey,
pmt.prod_code_skey,
pmt.processor_txn_id_fieldname,
pmt.sf_skey,
pmt.sf_lineitem,
alog.skey as alog_skey,
alog.atrig_skey as atrig_skey,
alog.pp_skey,
atrig.payment_amount as atrig_pay_amount,
atrig.processor_txn_id,
atrig.processor_txn_id_fieldname,
alog.atrig_payment_date,
sfl.skey as sfl_skey
FROM `tbluserlevels` ul
left join tblusers u on u.nUser_ID=ul.nUser_ID
left join hwc_payments pmt on ul.nUserLevel_ID = pmt.nUserLevel_ID
left join product_codes pc on pc.skey=pmt.prod_code_skey
left join hwc_activations alog on alog.skey=ul.alog_skey
left join activation_triggers atrig on atrig.skey=alog.atrig_skey
left join product_master pm on pm.skey=pc.prod_skey
left join sales_forms sf on sf.skey=ul.sf_lineitem
left join sales_forms_lineitems sfl on sfl.sf_skey=sf.skey
left join pay_processor pp on pp.skey=alog.pp_skey
WHERE u.`cookie_id` ='". $lookup."'
and sfl.prod_code_skey=".$class['prod_code_skey'];


puttrace(__LINE__,__FILE__);
$lineitems=getRows($sql, $GLOBALS['classConn'], strval(__LINE__).__FILE__);
if(count($lineitems)==0):
	eko('error, programmer needs to fix this (class admin '.strval(__LINE__));
elseif(count($lineitems)>1):
	eko('error, programmer needs to fix this (class admin '.strval(__LINE__));
else:
	foreach($lineitems[0] as $key=>$value):?>
		<div class="row">
			<div class="col-sm-6">
				<?= $key ?>
			</div>
			<div class="col-sm-6 white_on_blue myfont3 five-pad smaller">
				<?= $value ?>
			</div>
		</div>
		<?
	endforeach;
endif;

kurdtpage · 2018-01-03 03:24:42 UTC

You could try this code

Songworks · 2018-01-03 04:05:53 UTC

In both of your code examples are<? in it. So, is short_open_tag On in whichever php.ini you are now using for the local php/linter?

Wliu · 2018-01-03 04:14:37 UTC

Quickly jumping in here: you can get rid of the vertical line by disabling the wrap-guide package.

danallen · 2018-01-10 20:35:44 UTC

Ok, I finally got this together. I dropped the red dots by copying the php.ini from my server where this php runs to the default instance of php on my workstation. You suggested that awhile ago, and I finally let the light in. Thank you for your help solving the problem.

Thank you for directing me to that setting.

When Soft Wrap at Preferred Line Length is DISABLED, should that guide get the hint and disappear itself?

danPadric · 2018-01-10 20:56:17 UTC

Hello @danallen,

That is not going to help you.

What he meant shown in a picture ->

The add-on package that is responsible for the functionality can be disabled.

Bonus notes: The base install of Atom comes with some packages that are called “Core Packages”. For performance enhancement or for cases like yours, these can be switched off. For your workings with Atom you might even switch off (disable) Python, Ruby and C grammar packages as you do not use them.

Regards.
- Dan Padric

Wliu · 2018-01-10 22:00:37 UTC

No, if that setting is disabled the line soft wraps at the edge of your screen.

EDIT: Actually I totally misread what you said. That kinda sounds reasonable for the line to disappear, though some people might be using it as an “unofficial” guide.

DamnedScholar · 2018-01-10 22:23:54 UTC

I do this, particularly when I’m writing Python since I think PEP8 style is aesthetically pleasing. It would make sense to have a setting on wrap-guide to support the other behavior as well.

danallen · 2018-01-10 23:35:13 UTC

I don’t think you have the information to make that statement. I provided no context for my question. It happens that my objective in asking that question was to observe the response it would receive and in that regard, it helped me.

I almost always am offended when people I don’t know and who don’t know me provide unsolicited feedback on the usefulness of my questions. I appreciate your time,assistance, and expertise with regard to Atom. I am confident that I do not require assistance determining what will be helpful to me to ask regarding Atom,

Do you usually need help asking questions reflecting what will be helpful to have answered? I would say practically no one needs that assistance with regard to technical matters.Assimilating into a new community would different, but that is off topic.

Since asking that question, I have learned it makes sense for the line to disappear when Soft Wrap at Preferred Line Length is DISABLED, but for reasons unknown to me the line remains.

On a hunch I tried moving the vertical line out of vislble range:
!

image|377x193

It might have been months before I foundd settings affecting that line.

Dan, Thank you for bringing the package scheme and the option of disabling core packages to my attention. That sounds like it could potentially be a terrific way for faciiitating a modular structurein the system . making it possible for a lot of developers to work collaboratively.

I wonder if I could convert the systems I work on into a similar structure.

I am going to need to isolate the core of Atom with no packages, not even the core packages.

DamnedScholar · 2018-01-11 04:05:09 UTC

The core of Atom with no packages is a text editor with few features but an API that lets you do just about anything. Atom then treats all packages as Node.js modules with special behaviors for a small list of directories including styles/, config/, grammars/, and others. The APM utility functions similarly to Node Package Manager because it’s based on NPM and an Atom package looks exactly like a Node package. Atom has some sophisticated tools like caching, notifications, and not crashing when an invalid package is loaded, but at the most primitive level you can make any Electron program modular by having it require() the contents of an external directory. Node handles everything else.

danPadric · 2018-01-11 19:02:42 UTC

OFF-TOPIC

I feel now as if I should walk on eggshells when interacting with you.

This is true.

I make assumptions and speak out opinions; even predict what you’ll find interesting. It is a calculated risk. Only you will be able to evaluate if those are accurate or helpful. Reread the That is not going to help you as an opinion instead of a hard fact.

When I am wrong with my answers, I rely on your interactive reply. With a co-operative conversation I (or even someone else) better understand what you are asking and you better understand what I am suggesting. If all goes well we meet each other somewhere in the middle.

I am okay with being wrong. I am okay of having difference in opinions.
Will you be okay with not making me walk on eggshells?

Now the most important part…
Welcome to the community. You are most welcome … just the way you are.