27

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.

MirroredFate
  • 12,396
  • 14
  • 68
  • 100
  • `Banging my head on a wall in frustration` do you have sufficient SSH access to be able to perform the php command? – iam-decoder Aug 15 '14 at 16:49
  • Does the file has syntax errors and just terminates? - try by issuing `php -l < my_script.php` – MrTux Aug 15 '14 at 16:51
  • Issue with Permissions? You can do a `chmod +x` on the file just in case – DaGhostman Dimitrov Aug 15 '14 at 16:54
  • When you say it works in a *different terminal* do you mean a different terminal application or in another instance of the same terminal? – Joshua Shearer Aug 15 '14 at 16:57
  • @JoshuaShearer Another instance of the same terminal. – MirroredFate Aug 15 '14 at 17:41
  • @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 Aug 15 '14 at 17:42
  • @MrTux I introduced syntax errors just to get a failure message to output. Still nothing. – MirroredFate Aug 15 '14 at 17:42
  • @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 :/ – MirroredFate Aug 15 '14 at 17:44
  • 3
    php -d display_errors=1 -f my_script.php myArguments – Mike B Aug 15 '14 at 17:44
  • 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? – Joshua Shearer Aug 15 '14 at 18:02
  • @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. – MirroredFate Aug 15 '14 at 18:21
  • Does `php -a` drop you into an interactive prompt? If so, does something like `echo "test";` output anything there? – Joshua Shearer Aug 15 '14 at 18:28
  • @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 Aug 18 '14 at 19:48
  • @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. – MirroredFate Aug 22 '14 at 16:58

4 Answers4

30

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
Mike B
  • 31,886
  • 13
  • 87
  • 111
  • 1
    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 – Lorenzo Marcon Jan 17 '16 at 12:42
  • You may also need `-d error_reporting=E_ALL`. – mwfearnley Jun 01 '23 at 08:36
22

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

Tim
  • 491
  • 3
  • 6
  • 1
    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. – Andy Borgmann Apr 18 '22 at 22:19
  • I think in many cases `-n` only works because php.ini is limiting the amount of errors shown. So a nicer way is to do `-d error_reporting=E_ALL`. Note, there's a full list of error types at https://www.php.net/manual/en/errorfunc.constants.php. My particular error was picked up by `E_COMPILE_ERROR`. – mwfearnley Jun 01 '23 at 08:42
1

I recently had this issue and it was because I didn't wrap my test file in <?php & ?> tags.

Z-100
  • 518
  • 3
  • 19
Data_Dork
  • 11
  • 3
0

I experienced PHP CLI failing silently on a good script because of a memory limit issue. Try with:

php -d memory_limit=512M script.php
Marco Marsala
  • 2,332
  • 5
  • 25
  • 39