Bug 86037 - dircolors defines a file type it later claims it can't handle
dircolors defines a file type it later claims it can't handle
Product: Red Hat Linux
Classification: Retired
Component: fileutils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-03-12 14:53 EST by C.M. Connelly
Modified: 2007-04-18 12:51 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-03-17 09:06:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description C.M. Connelly 2003-03-12 14:53:44 EST
Description of problem:

``dircolors -p'' prints out a list of the file types that can be colorized (with
ls --color) that can be modified.  One of these is 

   DOOR 01;35	# door

When you use ``eval `dircolors <dbfile>`'' to reload your modified database, or
even just ``eval `dircolors`'' to restore the color database to the default, it

   Unknown colorls variable `do'.

The colors are changed, however.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.  eval `dircolors`


1. dircolors -p > foo
2. eval `dircolors foo`

Actual results:

Error message  Unknown colorls variable `do'.

Other colors are changed.

Expected results:

Colors are reset with no output to terminal.

Additional info:

The color database in /etc/DIR_COLORS does not include the DOOR entry.  (And
also doesn't really match the output from ``dircolors -p'' at all.)
Comment 1 Tim Waugh 2003-03-17 09:06:40 EST
Seems to work fine in the coreutils in rawhide.

Note You need to log in before you can comment on or make changes to this bug.