Bug 457342

This happens with bash too.  Any terminal, I would guess.

It also prevents (sometimes) execution of the su command, even after sourcing
.cshrc.

Happily I managed to fix all my computers by installing an older version of
coreutils.  So coreutils is indeed the problem.

I get the following when opening a tcsh shell window: "Unknown colorls variable
`ca'". Downgrading coreutils also works for me.

Thanks for your report.

This is caused by adding new color attribute to ls for highlighting file 
capabilities as requested in #449985.

This issue is bug of tcsh reported as #186037 and it should be fixed. But it 
does not work for me even on rawhide, maybe #186037 should be reopened.

Adjusting of LS_COLORS variable could help.

But I can't reproduce this bug on any other shell than (t)csh. Can you attach 
any example? And if you thing that su is broken by ls colors, an example would 
be nice, too.

(In reply to comment #3)
> Thanks for your report.
> 
> This is caused by adding new color attribute to ls for highlighting file 
> capabilities as requested in #449985.
> 
> This issue is bug of tcsh reported as #186037 and it should be fixed. But it 
> does not work for me even on rawhide, maybe #186037 should be reopened.

I don't understand "it does not work".  What is "it"?  And does "work" mean that
you get the error or that you do not get the error?
 
> Adjusting of LS_COLORS variable could help.

I tried set LS_COLORS=null and it didn't help.

> But I can't reproduce this bug on any other shell than (t)csh. Can you attach 
> any example? And if you thing that su is broken by ls colors, an example would 
> be nice, too.

You are probably right about bash.  I wasn't really in bash when I tried it.  I
thought I was.

I don't know what you want for an example of su failing, but here is what
happens.  Note that the prompt does not change, and I cannot access files such
as /var/log/messages.

baron@bloch ~ $ su
Password: 
Unknown colorls variable `ca'.
baron@bloch ~ $ 

As I said originally, though, this does not always happen.  In particular, it
seems to happen only when I open a new terminal window.  In an old window, su
works, even though I still get this error message and .cshrc is not read until I
source it.

Is someone going to re-open the tcsh bug, or should I do it?

(In reply to comment #4)
> I don't understand "it does not work".  What is "it"?  And does "work" mean 
that
> you get the error or that you do not get the error?
Sorry for confusion. I wasn't able to start tcsh with new version of coreutils 
and default environment on F-9 and rawhide.

> I tried set LS_COLORS=null and it didn't help.
$ tcsh || echo error starting tcsh
Unknown colorls variable `ca'.
error starting tcsh
$ export LS_COLORS=
$ tcsh || echo error starting tcsh
Unknown colorls variable `ca'.
$ echo $0
tcsh

> baron@bloch ~ $ su
> Password: 
> Unknown colorls variable `ca'.
> baron@bloch ~ $ 
What does say 'whoami' command? Did you try 'su --shell=/bin/bash'?

> Is someone going to re-open the tcsh bug, or should I do it?
I am not sure, maybe went something wrong in new coreutils version. But this 
seems to be an tcsh issue since other shells work properly. 

Worth reassigning to tcsh to get the tcsh maintainer's opinion?

Created attachment 313092 [details]
add new color attribute for file with capability

As requested in #449985 new color attribute was added to ls for file with 
capability. But new version of coreutils broke tcsh. Patch in comment #7 adds 
this attribute (ca) to tcsh.

It will be also good to improve tcsh to start, even though any color attribute 
is missing. It should be fixed by #186037 as mentioned above, but it seems not 
to work properly.

*** Bug 456925 has been marked as a duplicate of this bug. ***

*** Bug 457397 has been marked as a duplicate of this bug. ***

Since there are a lot of bugs reported changing severity to urgent.

*** Bug 457438 has been marked as a duplicate of this bug. ***

Downgrading coreutils worked for me also. BTW is there a mechanism in Yumex to
do a downgrade? I couldn't find one, I had to download the rpm and then install
using a --force switch. There needs to be a simple way to rollback updates so
that you can recover from screwups like this. 

There also needs to be some discipline among the Fedora maintainers, this isn't
the first time that they've cavalierly thrown an untested update out that broke
something fundamental. Tcsh is not some obscure application, it's absolutely
essential. I couldn't even do an su so that I could open Xemacs as root and edit
the /etc/passwd file, I had to log out and then log in as the root user in order
to fix it. 

*** Bug 457472 has been marked as a duplicate of this bug. ***

*** Bug 457481 has been marked as a duplicate of this bug. ***

Created attachment 313153 [details]
patch which solves this problem generally (maybe lost patch from tcsh-6.14-8 during a tcsh rebase)

Maybe adding "colorls" to the summary would limit number of duplicates? I know I
was searching for it first and found nothing.

(In reply to comment #17)
It was nonsense to close the (preceding) original report, namely bug 456925,
as duplicate. That one had a clear summary including the key word 'colorls'.

coreutils-6.10-30.fc9 has been submitted as an update for Fedora 9

New color was removed from dircolors and built as coreutils-6.10-30.fc9.

A quick solution, without downgrading coreutils, is the following:

1. cd $HOME
2. dircolors -p > .dircolors
3. edit .dircolors commenting out the following line:
   CAPABILITY 30;41 # file with capability

After that, when you open a (t)csh session, this new config file is read and the
error is gone.

> New color was removed from dircolors and built as coreutils-6.10-30.fc9.

This update does not show up yet. When will it be released?

(In reply to comment #21)
You can download it now from
http://koji.fedoraproject.org/koji/buildinfo?buildID=58220

This is temporary link to pending update:
https://admin.fedoraproject.org/updates/F9/pending/coreutils-6.10-30.fc9

The new version works for me, and the solution in #21 (which also worked) is no
longer needed.  Thanks.

For others, remember that, if you use yum localupdate for this before the new
rpm is official, you have to say --nogpg.

It worked for me also.

*** Bug 457634 has been marked as a duplicate of this bug. ***

When is the fixed version of Coreutils, 6.10.30, going to be put into the updates repository? As far as I can tell the broken version, 6.10.28, is still poisoning the updates repository.

coreutils-6.10-30.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

*** Bug 458503 has been marked as a duplicate of this bug. ***

After a fresh install of current "rawhide", I am again confronted with the already familiar "Unknown colorls variable `ca' message. Not setting LS_COLORS in .cshrc does not help either.". Resourcing .cshrc sets the C-shell up as expected. Package information:
- coreutils-6.12-8.fc10.x86_64
- tcsh-6.15-4.fc9.x86_64

(In reply to comment #29)
coreutils-6.10-30.fc9 was built as F-9 workaround for this bug, it does not fix the tcsh bug in any way. That's why this bug is still opened. I hope it will be fixed soon in F-9 and rawhide as well.

tcsh-6.15-5.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/tcsh-6.15-5.fc9

tcsh-6.15-5.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update tcsh'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7562

tcsh-6.15-5.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.