PHP cli script does not output anything

Question

So I have a php script which I execute using the following command:

php -f my_script.php myArguments

The script is under version control using svn. I just updated it, pasted the command to run it into a terminal, and executed it. However, there is no output. Not a failure message, not it printing anything, nothing. It looks like it never starts. Kind of like the following:

me:/srv/scripts# php -f my_script.php myArguments
me:/srv/scripts#

Other scripts will run just fine.

It is difficult for me to come up with an SSCCE, as I can't really share the code that is causing this, and I haven't been able to replicate this behavior intentionally. I have, however, seen this twice now. If I save my changes, revert the file, and paste them back in, there is a strong chance it will run just fine.

However, I am concerned by not knowing what is causing this odd behavior. Is there a whitespace character or something that tells PHP not to start, or output anything?

Here is what I've tried after seeing this behavior:

• Modifying the script so it is a simple echo 'hello'

• Putting nonsense at the beginning of the script, so it is unparseable.

• Pasting in code from a working script

• Banging my head on a wall in frustration

• Trying it in another terminal/putty ssh connection.

Here's where it gets interesting: It actually works in a different terminal. It does everything as expected.

So does anyone have any ideas what might be causing this, or things I should try in order to determine the problem?

EDIT:

The "different terminal" is still the terminal application, just a new one.

I have sufficient permissions to execute the file, but even if I didn't, it should spit out a message saying I don't.

I intentionally introduced syntax errors in hopes that I would get PHP to spit out a parse error. There was still no output.

Solution 1

display_errors might be disabled before runtime. You can turn it on manually with the -d switch:

php -d display_errors=1 -f my_script.php myArguments

Solution 2

I came across the same issue, and no amount of coercing PHP to display_errors or checking for syntax with -l helped

I finally solved our problem, and perhaps you can find some help with this solution

Test your script without using your php.ini:

php -n test_script.php

This will help you hone in on the real cause - PHP configuration, someone else's script, or your script

In my case, it was a problem with someone else's script which was being added via the auto_prepend_file directive in the php.ini. (Or more specifically, several files and functions later as I drilled through all the code adding debug as I went - on a side note, you may find that using fwrite(STDOUT, "debug text\n"); invaluable when trying to debug this type of issue)

Someone had added a function that was getting run through the prepend file, but had used the @ symbol to suppress errors on a particular function call. (You might have a similar problem but not specifically related to the php.ini if you have any includes in your test script bringing in other code)

The function was failing and caused the silent death of PHP, nothing to do with my test script

You will find all sorts of warnings about how using the @ symbol causes the exact problem I had, and perhaps you're having, http://php.net/manual/en/language.operators.errorcontrol.php.

Reproduction of similar symptoms:

Take a fully functional PHP environment, and break your CLI output by adding this the top of your script @xxx_not_a_real_function_name_xxx();

So you may just have a problem with the php.ini, or you (or someone else) may have used @ not realising the serious (and frustrating and time consuming) consequences that it causes in debugging

Comments

[iam-decoder]

Banging my head on a wall in frustration do you have sufficient SSH access to be able to perform the php command?

[MrTux]

Does the file has syntax errors and just terminates? - try by issuing php -l < my_script.php

[DaGhostman Dimitrov]

Issue with Permissions? You can do a chmod +x on the file just in case

[Joshua Shearer]

When you say it works in a different terminal do you mean a different terminal application or in another instance of the same terminal?

[MirroredFate]

@JoshuaShearer Another instance of the same terminal.

[MirroredFate]

@iamde_coder Yes, I have the appropriate access. In fact, I can execute other php scripts just fine. I am only have trouble with one specific one.

[MirroredFate]

@MrTux I introduced syntax errors just to get a failure message to output. Still nothing.

[MirroredFate]

@DaGhostmanDimitrov It does not have execute permissions as it is a php script, not a bash script. Even were that the case, however, I should get an error message. I get nothing :/

[Mike B]

php -d display_errors=1 -f my_script.php myArguments

[Joshua Shearer]

So if you open two instances of the same terminal it will never work in the first instance but always works in the second instance?

[MirroredFate]

@JoshuaShearer That is correct. However, if you are ssh'ed in from putty and open another instance of putty, it will not work from either.

[Joshua Shearer]

Does php -a drop you into an interactive prompt? If so, does something like echo "test"; output anything there?

[MirroredFate]

@JoshuaShearer Sorry for the late reply. The weekend hit. I don't actually know, as the shell session timed out. This problem has only cropped up twice, and rather sporadically, so I will try the things suggested here next time I see it.

[MirroredFate]

@MikeB The problem was that display_errors was off in the .ini file. Presumably the scripts where we've seen no output have just had a syntax error. If you want to post it as an answer, I'll accept it.

[Lorenzo Marcon]

this helped me a lot. I had an old php.ini with allow_call_time_pass_reference set to On, but since it's not available anymore, every script run by cli failed without output. Using -d display_errors=1 threw: PHP Fatal error: Directive 'allow_call_time_pass_reference' is no longer available in PHP in Unknown on line 0, helping me to fix the error by removing that line from php.ini. Thanks sir

[Andy Borgmann]

I can't even begin to describe how helpful this was. I have worked with PHP for 18 years now, and I didn't know about php -n and that pointed in me the right direction. For me, it was on a prepend file that I was purposely using, but we have a check in there to check for SSL and if not to forward to SSL. That worked fine in PHP7, but in PHP8 it appears to try and redirect the CLI. Weird there was no error though. THANK YOU so much.