Undefined constant "Kint\Renderer\STDOUT" in 4.1

[kenjis]

What happened?

Fatal error: Uncaught Error: Undefined constant "Kint\Renderer\STDOUT" in .../kint-test/vendor/kint-php/kint/init_helpers.php on line 68

How to reproduce:

$ composer require kint-php/kint --dev

test.php:

<?php
require __DIR__ . '/vendor/autoload.php';
s('test');

$ php -S localhost:8080 test.php

• OS: [macOS 10.15.7]
• Web server [PHP built-in]
• PHP version [8.0.14]

[jnvsor]

Hi @kenjis I wasn't aware there was any context where STDOUT wasn't available... My mistake. I've made a patch release to fix that

@DRSDavidSoft Just to be sure, can you take a look and make sure it still works on windows? (There shouldn't have been any change logic-wise)

[DRSDavidSoft]

@jnvsor Will do soon; I wasn't aware that STDOUT could be undefined on some contexts.

Sad thing that this meant the one liner to check windows_output is now expanded to several line, but now this allows for easier tweaks.

Also, maybe you can make use of is_resource() for the property, for additional validation. Just an idea!

I'll test the CLI output on Windows as soon as possible.

[kktsvetkov]

@jnvsor what about if you just import the constant instead? I mean like this:

namespace Kint\Renderer;

use Exception;
use Kint\Zval\Value;
use Throwable;

use const STDOUT;

class CliRenderer extends TextRenderer
{ ...

[DRSDavidSoft]

@jnvsor Tested, and confirmed that everything works correctly.

This issue can be closed, however, I have another question:

(moved to #380 as it was a bit off-topic for this issue)

[jnvsor]

@kktsvetkov Constants are like functions, if it can't find it in the current namespace it checks the global. Turns out his STDOUT isn't defined at all, that's why this error occurred. (So importing it would just change it to "Undefined constant STDOUT")

@kenjis I couldn't reproduce this with my own php -S so it's possible there's something context-specific to your system. Can you confirm that 4.1.1 fixes it?

@DRSDavidSoft Great

[DRSDavidSoft]

@jnvsor The documentation says that STDOUT is equivalent to fopen('php://stdout', 'w'), and that apparently these constants are defined in the CLI only:

The CLI SAPI defines a few constants for I/O streams to make programming for the command line a bit easier.

So actually I thought STDOUT was SAPI agnostic, and also would be defined in the regular CGI interface. Just did some tests, and it appears in the built-in server it's not the case.

I think 4.1.1 fixes this issue neatly, and if for whatever reason output to the console from CGI is ever needed, the constant needs to be manually defined.

if ( !is_defined('STDOUT') ) define('STDOUT', fopen('php://stdout', 'w'));

Sorry that #319 caused this bit of additional trouble, hopefully everything works correctly now! Thanks for the work you do ❤️

[jnvsor]

apparently these constants are defined in the CLI only

That's the thing they are defined everywhere - at least normally. In apache it's also defined by default because that's how the page output gets from PHP to the webserver (And I assume in nginx too)

Edit: Apparently I'm getting mixed up. I guess that's how it sometimes outputs to the webserver (In CGI mode instead of apache module?) but not currently on my system. Long story short it's usually defined :)

[kenjis]

I couldn't reproduce this with my own php -S so it's possible there's something context-specific to your system. Can you confirm that 4.1.1 fixes it?

I confirmed 4.1.1 fixed the error.

[jnvsor]

Great

[kenjis]

In this case, Windows Apache does not have STDOUT.
And I've confirmed that Apache on Docker (php:7.4-apache-buster) also does not have.