Cannot use `require` or similar in shell, PHP 7.3.5

[Peter Beckman]

PHP: 7.3.5
PSYSH: 0.11.9, 0.11.10

Sometimes I manually include or require to test something. This used to work, but as of 0.11.9 (maybe earlier) and 0.11.10 when I run the command $a = require_once 'file.php'; $a is left unset, and the code is not included in the shell. No error is thrown, seemingly nothing occurs. Using sudo also does not seem to work.

The command is also not included in the command history.

This affects require, require_once, include, and include_once.

I am initializing a base code behind it using a configuration function, and that does include Composer.

I didn't see anything in the notes about this in the release notes or Wiki, and it seems strange that I can no longer do so.

I am currently using an older version of PHP, 7.3.5, but I do not see support for that discontinued yet.

This has worked fine in previous versions of PSYSH so it not working now came as a bit of a surprise! Let me know if this is a known issue, or related to my own setup, or a PHP 7 issue.

[Justin Hileman]

That is weird. Can you download the previous build from the releases page and see if it works for you?

[Justin Hileman]

Can you also paste the output from running \psy\info() inside the shell?

[Justin Hileman]

I'm unable to reproduce this on PHP 7.3.33.

[Peter Beckman]

tl;dr -- Code error in the include file, PHP Fatal error. Wasn't thrown in PSYSH so I was just confused. NOT A BUG, SORRY!

Long Version, with Question at the bottom --

Well that is interesting.

So it seems like I'm doing a require on a file that I've modified, and the modification seems to be causing a silent error. I've linted the file using php -ln file.php and no errors, but for some reason, once I try to pull it into psysh the require completely and entirely fails, no errors, no normal PHP return value (should return false if the require fails, but I get no return value.

CoreLogic Engine loaded. // This is my custom function that loads the base/core libraries.
= true

// Non-working example
> require_once 'common/file.class.php'
<aside>return require_once \Psy\CodeCleaner\RequirePass::resolve('common/file.class.php', 1);</aside>
> 

// Working example
> require_once 'common/file2.class.inc';
<aside>return require_once \Psy\CodeCleaner\RequirePass::resolve('common/file2.class.inc', 1);</aside>
= 1

>

So it turns out a PHP Fatal error was being thrown, but I was not looking in the correct log file.

[04-Jan-2023 02:13:22 UTC] PHP Fatal error:  fileext cannot implement fileapiext - it is not an interface in /<PATH>/include/common/fileext.class.php on line 25

So this is a code error on my part. My apologies for blaming PSYSH!!!

Since I have you, why would this PHP Fatal Error be logged, but be completely silent in the psysh interface?

EXPECTATION
Fatal Error is output on the command line. Even if it is just notifying me of a fatal error that is lost when PHP dies.

ACTUAL
Complete silence about any fatal error, or that the code failed to execute entirely.

[Justin Hileman]

Either your configured error logging level is too low so the error is suppressed in PsySH, or something in your local environment does something different with the errors preventing PsySH from handling them. By default, PsySH would log that error to the screen:

<?php

class Foo {}
class Bar implements Foo {}

Edit: actually! That error isn't written to the screen by PsySH, it's written to the screen by PHP itself. PsySH doesn't get a chance to do anything with it, as the fatal error happens while the require is being executed and control never returns. So whether or not you see that probably is entirely determined by your PHP config or some local code that messes with PHP config :)

[Peter Beckman]

Ahhh yes I have that turned off in my config, since it runs on the web, and we don't want customers seeing errors. I'll see if I can set it to output Fatal Errors to the screen when running in PSYSH to avoid such things.

My apologies -- nothing is wrong with PSYSH and I am fired. Thanks for digging into this with me @bobthecow !!

[Justin Hileman]

No worries, glad you got it sorted!

[Justin Hileman]

Oh! In your PsySH config you can set errorLoggingLevel to something different than default :)

Edit: gaaaah actually that won't help. I forgot that bit about this error being outside of PsySH's control :(

Per the docs you can make a php-cli.ini that'll take precedence over php.ini when running from the command line.

[Peter Beckman]

I thought I had that... looking.

Yep, don't have a separate CLI config.

Here's what I added to fix it in my Config for PSYSH. I have a function I call when doing this work, so I just added these lines to that function:

// Enable debugging to screen
ini_set('display_errors', 'On');
ini_set('display_startup_errors', 'On');
ini_set('html_errors', 'Off');
ini_set('track_errors', 'On');

Maybe throw an error or log entry when starting up if these INI Settings are not this way? Or automatically set these, since it won't hurt the running PSYSH configuration?

Just adding this for future me and anyone else that is confused by this! Working now.