Artisan and empty lines in a containerized environment

[mystygage]

• Laravel Version: 9.21.6
• PHP Version: 8.1.8
• Database Driver & Version: mariadb 10

Description:

Artisan's fresh look introduced in #43065 is really beautiful, but two empty lines are added to each call when a command like php artisan schedule:run is executed. This improves the readability immensely when these commands are executed in a developer's console.

As we run this command every 60 second in a containerized environment with log collection this creates a lot of noise:

[...]
service   |
service   |    INFO  No scheduled commands are ready to run.
service   |
service   |
service   |    INFO  No scheduled commands are ready to run.
service   |
service   |
service   |    INFO  No scheduled commands are ready to run.
service   |
service   |
service   |    INFO  No scheduled commands are ready to run.
service   |
[...]

It would be awesome to have an option like --compact to remove these empty lines.

Steps To Reproduce:

Run a command like php artisan schedule:run and observe the empty lines around the actual response:

laravel@fc3108fb14:/var/www/html# php artisan schedule:run

   INFO  No scheduled commands are ready to run.

[nunomaduro]

Sorry, at this time there is no built-in solution for this. You can, of course, use bash in docker to "trim" those extra lines so they don't appear in your logs.

We will wait for a few more reports, to see if this is effecting other people.

[Namoshek]

@nunomaduro This is affecting us as well. Actually it's not only the empty lines but also the whitespace at the start of each line which requires additional attention. In a containerized environment, this is extra difficult because simply piping the output of php artisan schedule:run or similar into grep, awk or whatever will not work:

exec php artisan schedule:run --periodic | awk NF

In this case --periodic is a daemon flag from us, but due to the pipe, the php artisan schedule:run --periodic process does not have PID 1 and therefore does not listen to signals. This can be fixed as described here, but it seems quite overkill for a basic request.

Would it be possible to use the --no-ansi Flag to reduce the output from within the framework (to avoid introducing a new option)?