No I have not read that issue until now, But there again just remember it doesn't hurt to stay with a stable version that's working for a while and not go updating every two weeks.

I used 5.1 for a long time until 5.5 came out, then I did start with a 5.8 just in prep for the next stable released which was long-term support, 6.0

I think the problem is some folks upgrade weekly and that's totally unnecessary. They don't even give the developer team time to work out Kinks.

On the 6.* version I probably won't even mess with updating but every four months in development. Not every two weeks however.

I just tested everything on my big brother's computer and he doesn't have an issue like mine. I tried reinstalling everything but it still persists, which is weird because I just did a git clone and composer install and everything is working on his computer

Apparently downgrading to 4.3.4 is also the only fix for me too.

This looks to me that there is something off with the character set used on your computer's teminal. So I suggest looking into that.

@jlrdw The issue began with me on 5.8

Like @tray2 said it has to be computer specific the char set or so, but what else can we do to straighten it out?

I will try to look at the changelog of symfony/console because whatever changed there caused a the difference between the way my computer renders the console and the way that most peoples computer renders the console to become apparent.

I just did a composer install on a laravel 5.8.16 that I got from https://github.com/laravel/laravel/tags

and here is the result of a php artisan list:

$ php artisan list
Laravel Framework ?[32m5.8.35?[39m

?[33mUsage:?[39m
  command [options] [arguments]

?[33mOptions:?[39m
  ?[32m-h, --help?[39m            Display this help message
  ?[32m-q, --quiet?[39m           Do not output any message
  ?[32m-V, --version?[39m         Display this application version
  ?[32m    --ansi?[39m            Force ANSI output
  ?[32m    --no-ansi?[39m         Disable ANSI output
  ?[32m-n, --no-interaction?[39m  Do not ask any interactive question
  ?[32m    --env[=ENV]?[39m       The environment the command should run under
  ?[32m-v|vv|vvv, --verbose?[39m  Increase the verbosity of messages: 1 for norm
al output, 2 for more verbose output and 3 for debug

now let me see if I can figure out another way to get this fixed other than downgrading symfony/console...

your terminal is not interpretting the ansi colour codes.

In the first instance use --no-ansi on your commands

And I have used artisan on all versions, I have never had to downgrade anything.

However I have had to update composer at times to get an install to work.

@snapey absolutely correct with no --no-ansi color is gone but the list is legible.

so is it a git thing? what can I do to fix it on my end?

This https://stackoverflow.com/questions/22203950/composer-returning-question-marks Might not apply, but have a look. I just never encountered that, yet, but I probably will some day.

its down to the WSL terminal application being used

@snapey Exactly, when I use windows cmd all is well but when I use git bash I get the gibrish unless I use the --no-ansi flag?

also I just updated to the latest version of git and it did not change. I gues I updated to WSL2?

are you a vs code user? if so, try the terminal in there

PHP storm and git bash, phpstorm has a windows style cmd on windows.

My version of window 10 can only use WSL1 I imagin WSL2 would fix my problem but my window 10 build version is to old, I will build me another computer soon that has a newer version of w10.

Sorry I hiijacked this post but I had the problem back in laravel 5.8

Thank you.

composer require symfony/console:4.3.7

also works which is an upgrade...

FYI symfony/console 4.3.7 was released today which appears to fix this issue. I just tested it on my Win10 running CygWin and it's fine (wasn't before 4.3.7). So doing a composer update or composer update symfony/console should get you back to normal. I know it had been driving me crazy since L6.1!

Those are escape codes, looks to me like the environment isn't configured to display colors/etc, but it's still outputing the ansi escape codes to set output colors.

Curious. @lemmon what do you have for TERM in the output of env?

I am sorry I do not know what TERM is it is not in my .env

--no-ansi

no colors but no ?

Not .env.. the env command, in bash.. unless you're using windows' cmd instead which is probably the entire issue in and of itself. but bash, even git bash, ought to properly support ansi escape codes.

?[33mOptions:?[39m

The ?[ represents the start of an escape string, 33m sets the foreground color to yellow, 39m sets it to the default/white.

This is why explicitly setting the --no-ansi flag prevents the output, but it oughtn't happen if your terminal is set to the appropriate terminal emulation mode, allowing ansi escape codes to work properly. Suspect given this is associated with a specific version of symfony console that version introduced a bug preventing proper detection of terminal ansi support or something that was otherwise previously disabling the ansi sequences automatically.

Was a windows user for years, but between the past several years working on a mac, and many years working with various linux flavors... I could never go back to using windows for dev. ... and I tried just within the past month. I just can't get a comfortable environment in windows the way I can with either of the other two. Dunno how people do it...

windows cmd works fine however git bash for windows does not...

Read the whole tjread, it has all been discussed. and as you say, @willvincent it is a windows thing, to be more precise a git bash thing. but symfony/console:4.3.7 compensates for the git bash shortcoming.

Thank you for your help @willvincent. Please answer me this are you able to access the entire thread from beginning to end?

Ok, so it's a git bash problem, in that case it's definintely a terminal emulate setting problem. and again, the symfony component potentially failing to properly recognize the emulation does not support the escape codes properly.

Yes, of course I can see the whole thread.

I appreciate your feedback, Thank you. @willvincent

I was experiencing the same issue. Updating symfony to 4.4.0 resolved it. Thanks!

If you are using WIndows 10, I'm back on 5.2 and some 5.8. Lot's of info out there on how to make a simple regedit change and take all your troubles away. Here's one of many writeups on the issue I found:

https://stackoverflow.com/questions/48272340/laravel-artisan-commands-no-colors-in-cmd-terminal

This worked perfectly.

The rollback suggested above does not work for 5.2 dependencies.