I'm adding my vote to this enhancement. Directory colors are nearly unreadable with any background color, light or dark or anywhere in between. When using command-line build tools, I prefer to stay in the IDE if I can, but the default color scheme is clashes too badly.

I would recommend the Solarized scheme:

https://github.com/fentie/netbeans-colors-solarized
http://ethanschoonover.com/solarized

I agree. Colors are not the best. As workaround I changed background and foreground to be white on black

This would be great if it could be added.  AT the moment the terminal looks a little muted...

Yes, please add this.

I log a variety of messages to a file during unit testing and embed escape sequences in them to change colors identifying different things going on.  I would like to use the NB terminal window with "tail -f" to watch what happens.  rather than with an external terminal window.

There are many references, for convenience, here's one that discusses it in the context of a Bash Prompt at the bottom of the page:  http://bitmote.com/index.php?post/2012/11/19/Using-ANSI-Color-Codes-to-Colorize-Your-Bash-Prompt-on-Linux

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

I see multiple requests here (including comments from bug 248104).
(1) Better choice of default ANSI colors and/or user configurability.
(2) Use themes, Inherit colors from NetBeans editor L&F Themes.
    Multiple mentions of Solarized.
(3) Update emulation from TERM=xterm to TERM=xterm-256color
    In fact Term doesn't even handle the 16-color scheme.
    We could also consider going to 24-bit color.

For starters I'd like to mention that you can customize the foreground,
background and selection background colors via Tools->Options->
Miscellaneous->Terminal.

Re (1)
------
Well ANSI _is_ a standard and these _are_ default colors :-)
- One problem is that Term is really an 8-color scheme. In a proper
  "ANSI standard" 16-color scheme the primary, "Normal" colors are
  a bit more subdued and then you get the (8-15) "Bright/Intense" colors.
  Fixing this might help some of the garishness.
- Different terminals have assigned different default colors "near" the
  standard color. See https://en.wikipedia.org/wiki/ANSI_escape_code.
  So whom shall we mimic?

Re (2)
------
Let's discuss the concept of Themes. From the bug reports:
        Directory colors are nearly unreadable
        Take the colors from the editor or use solarized
        I would recommend the Solarized scheme
A theme is a mapping from semantic roles to a color. For example for
the NB text editor you have lots of semantic roles: Character, Comment,
Keyword etc. But a terminal doesn't have semantic roles ... it
just has foreground, background and assorted other _numbers_.
The "theme" comes from the application that's running under the terminal.
For example ...
- The color of the abovementioned Directory is dictated by 'ls(1)'
  color settings.
- One can configure 'vim' to use Solarized.

However, I see that at least Konsole has managed some sort of a theme,
including Solarized, where Colors are bound to the ANSI color numbers.
gnome-terminal has some UI for managing colors too but it's hela
less intuitive than Konsoles. So ... I guess this means TermOPtions and
it's UI will have to grow.

Re (3)
------
Is doable but there are several parts to it.
    (a) The relevant control sequences are:
            CSI 38;5;...m       choose fg color by index
            CSI 38;2;...m       choose fg color by nearest rgb
                                (of standard|current palette?)

            CSI 48;5;...m       choose bg color by index
            CSI 48;2;...m       choose bg color by nearest rgb

            OSC 4;,c>;<spec>ST|BEL
                                set palette color <c> to <spec>
            OSC 104;<c>ST|BEL   reset palette color <c> to default

        Term will need a default color palette like xterms:
            - Colors 16 through 231 make a 6x6x6 color cube
              number = 16 + 36 * r + 6 * g + b
              where  r, g and b in the range 0 - 5.
            - Colors 232 through 255 make 24 shades of gray from dark to light.

        We're fortunate that Term's character attribute uses an 'int instead
        of a 'short' so I can easily expand the 5 bits for color _index_ to
        8 w/o any new overhead.

        To go to 24-bit color though will require using a longword for
        attributes which will double the storage requirements. Fortunately
        this won't require any new sequences and can be accomodated later.

        The control sequences are straightforward to implement with the
        exception of the parsing of <spec> which can take many forms:
            <name>
            rgb:<r>/<g>/<b>             <r> = <g> = <b> = x | xx | xxx | xxxx
            #rgb, #rrggbb ...
            rgbi:<r>/<g>/<b>    <r> = <g> = <b> = [0.0 - 1.0]
            CIEXYZ:<X>/<Y>/<Z>
            ...
            See XParseColor(3)
         AndroidJava has a Color.parseColor() and so does JavaFX but we're
         Java and JavaFX is not supported on Solaris.
         So I'll start with just the default palette for now and postpone
         "set palette color".

    (b) Term has a "custom color" API which extends "CSI <Pm> m"
        with codes 50-57 and 60-67 where the colors can be assigned
        using Term.setCustomColor(). These originated from a _proposed_
        extension to DtTerm during the Sun Workshop days and It doesn't
        look like it ever made it into the official DtTerm.

        This whole API will be deprecated and in fact broken because
        we need to use codes 50-57 and 60-67 as indexes for the "light"
        colors in the 16-color scheme.

Plan
----
- Nix the "custom color" stuff.
- Go from 8-color to 16-color with Normal and Bright intensities.
- Implement the escape sequences
            CSI 38;5;...m       choose fg color by index
            CSI 38;2;...m       choose fg color by nearest rgb
                                (of standard|current palette?)
            CSI 48;5;...m       choose bg color by index
            CSI 48;2;...m       choose bg color by nearest rgb
  which will result in Term supporting a 256 color immutable palette.
  The "choose bg color by nearest rgb" sequences can later be extended to
  honor 24-bit color.
  FWIW I'll do the nearest match in HSB space instead of RGB space.

The next two are somewhat bigger projects:

- Support color theme's a'la Konsole/gnome-terminal.
  This is a whole lot of UI code and I don't think it can realistically
  be connected to NB Editor L&F settings.

- Support various Color <spec>'s by implementing
        OSC 4;,c>;<spec>ST|BEL  set palette color <c> to <spec>
        OSC 104;<c>ST|BEL       reset palette color <c> to default
  I can setup a framework and fans can add the various parsers.

(1) is fixed by Ivan in trunk