Closed jwrona closed 4 years ago
Haven't seen that no. A lot of variables would have to be ruled out, but one could argue this could not be a bug with LS_COLORS since gnome should not be dropping a stack trace just because you ran dircolors regardless of whether the input is not what it expected.
Yeah, I don't think it is a bug with LS_COLORS either. I've filed a bug report on Red Hat bugzilla, we will see.
Still an ongoing issue for me, I updated the bugzilla report with my findings.
Reducing LS_COLORS
to a max of ~8175 characters seems to fix this issue for me. Though this isn't a universal solution as it requires you to prioritise which entries you want to keep before blowing this limit.
Note that sourcing the complete set after logging in seems to work just fine, so this is just an issue when starting a gnome-session.
I think this issue was filed prior to the new installation instructions with install.sh
were added to the repository. The install script now pre-computes the LS_COLORS
var into a script in ~/.local/share
and invites the user to source that from the bashrc. This saves the step of running dircolors on every new shell session.
Although this does seem to be a bug somewhere in the Gnome stack you might try the new installation method as a temporary work-around. It may or may not help.
I tried this on the new installation method, still doesn't seem to make a difference.
I've added
eval $(dircolors -b path/to/LS_COLORS)
to my .bashrc file and everything worked. On the next reboot, GNOME Display Manager started but I was not able to log-in. Removing theeval
makes Gnome grat again. journalctl show this:Gnome bug? Any clues? Have you ever encountered this?