it's considerable to use the new Console dumper (#28898) for env var values, that would improve display as well.

The CliDumper hassetMaxStringWidth, so if we can pass such a value (as calculated here) we can depend on existing building blocks :)

something like

diff --git a/Command/AboutCommand.php b/Command/AboutCommand.phpindex b9fbe67..feee4e6 100644--- a/Command/AboutCommand.php+++ b/Command/AboutCommand.php@@ -12,6 +12,7 @@ namespace Symfony\Bundle\FrameworkBundle\Command;  use Symfony\Component\Console\Command\Command;+use Symfony\Component\Console\Helper\Dumper; use Symfony\Component\Console\Helper\Helper; use Symfony\Component\Console\Helper\TableSeparator; use Symfony\Component\Console\Input\InputInterface;@@ -90,12 +91,13 @@ EOT         ];          if ($dotenv = self::getDotenvVars()) {+            $dumper = new Dumper($io);             $rows = array_merge($rows, [                 new TableSeparator(),                 ['<info>Environment (.env)</>'],                 new TableSeparator(),-            ], array_map(function ($value, $name) {-                return [$name, $value];+            ], array_map(function ($value, $name) use ($dumper) {+                return [$name, $dumper($value, $maxLength)];             }, $dotenv, array_keys($dotenv)));         }

@ro0NL I'm not sure.Dumper::__invoke() does not allow to pass string's max length as the second parameter. Or are you suggesting to tweak its behaviour in this pr?

If so,dump's output is standing out with it's bright colours and double quotes from all the rest. Do we really want this?

If so, I could take a look into this.

Or are you suggesting to tweak its behaviour in this pr?

yep :)

If so, dump's output is standing out with it's bright colours and double quotes from all the rest. Do we really want this?

IMHO yes, but perhaps post a screenshot to see what others think. Maybe it's too much indeed ... i was mostly triggered for being able to reuseCliDumper::setMaxStringWidth :)

@ro0NL I decided against usingDumper since we would rely onCliDumper::setMaxStringWidth() and it is part ofVarDumper which is mostly a require-dev package, plus it adds a new dependency (on symfony/console).

So I rewrote it a bit and it looks quite nice. I added a pic

Could you please review my code?

@ro0NL fixed all

Not sure about this: while it improves the display, what if Ido want to get the full value, eg to copy/paste it somewhere else?

from experience, i agreeabout can be over-cluttered with output. Typically access tokens & co completely break the table

the original intend was always "debugging"; give a hint about the actual values being used. Truncating does not defeat this purpose IMHO.

what if I do want to get the full value

bin/console debug:container --env-var APP_SECRET :)

Wouldn't it make more sense to just remove this table with env vars?
There is alreadybin/console debug:container --env-vars if one wants to display them.

hmpf... yes. There's a subtle difference.. (envs managed by .env vs envs used in DI), but i agree it's not really significant.

Alternatively, what about displayingSYMFONY_DOTENV_VARS comma separated inabout, to not loose this feature (it's also shown in the webprofiler e.g.)

i tend to agree we should remove the Environment table inabout. Actually the web profiler shows the server parameters used for that request (and highlights which are from .env)... this concept doesnt exists for the console.

The current table was a solution, prior to the later addeddebug:container --env-vars.

Also we imply this are the actual values in .env, which is false :) the feature replacement is looking at .env really 😅

@ro0NL@nicolas-grekas ok, I see. I pushed a new commit which removes env var table completely.

Thank you@tuqqu.