OT: colors for vi on Linux (Debian - ubuntu)

[Fairlight]

Hi John,

The honourable and venerable John Esak spoke thus:
> Okay, I  know I'll take the flack for using this great forum to ask a
> question that seems non-filePro related.... I'll ask uit at the end of the

No flak here.

> minds of lots of folks who think like me.  I mean for the Linux crowd to
> have been working for so many years and still have not come up with a decent
> "color" setup a la "setcolor" from SCO...  it is just crazy.  

There -is- a colour (and other effect) setting program.  man setterm

Unfortunately, some curses-based applications don't play nicely with it
(read: most), as it doesn't actually always retain the colour if something
else (like filePro) takes over.  So I have to suffix all my fP commands
with setterm in aliases if I want that functionality.  I used to have to do
that with setcolor on SCO in some instances, so it's not that much worse.

> The bottom line is that filePro works dead easy on this box. (you really

I've never worked on a box on which fP wouldn't work easily, personally.
The only real issue has been making sure libtermcap is installed, since fP
version 5.0.10, as some dists like SuSE don't install it by default.

> now you will be hearing about ubuntu working well in many installations,
> just like you heard the same about suse for while and others.  Funny, but I

I hear people shouting the joys of Ubuntu all the time.  I won't use it for
personal reasons.  Briefly, if you read their web site, it's more of a
political movement than any advance in technology in and of itself.  We've
had quite enough politics with the OSS Foundation, the FSF, and the like.
I didn't really like Ubuntu's politics, either.

As for SuSE...don't start me.  Novell has -really- ticked me off in the
last two years.  They've released two lousy service packs, both of which
had issues that never should have made it past alpha, much less beta.  Then
there's the fact that one of my clients had a machine whose upgrade license
expired.  The gal at Novell said it should be "easy" to fix, and gave a
number at Novell to call.  The client was told that Novell wouldn't sell
the new licenses directly, you -had- to go through a reseller.  That was
supposed to take up to a week.  It ended up taking about two weeks in
reality.  And then there's their lack of willingness to stand behind their
product.  If a patch breaks something (even major, like the kernel!), they
don't care.  If you don't have a support contract, it'll cost you $675 for
an incident, or you have to start a contract with them, just to get to talk
to them officially--that's even though the system was working 10min ago,
and the only thing you did was install a patch that came directly from
their servers that made it non-functional.  Novell is -not- in my good
graces lately.  And I'm starting to debate the "best engineered" that I
used to concur with Bill Campbell on, given the last two service packs.
  
> learned that my PDA (which is the coolest Linux based thing in the world) is
> a Debian system... when I get to the console on this device through ssh, all
> the same commands as used on ubuntu work here.  Very cool.

Ah, the -coolest- linux-based thing in the world is probably the Korg Oasys
synthesizer workstation.  I've heard nothing but praise for that gear.  But
to each their own.  :)

> Now for my question.
> 
> The ls command does a lot of color changing for lots of different
> reasons.... directories, executable files, etc.  It is beyond annoying... If
> you have a black background like me... it is IMPOSSIBLE.  
> 
> I have gotten the great help from various folks and made the "ls" command to
> work like the "l" command I know and love (skipping the color thing) by
> doing this in my .profile....
> 
> type ls | grep -q alias && { unalias ls; echo unalias ls; }
> l ()  { ls -al $*; }
> lf () { ls -aCF $*; }
> 
> It stops the program from doing any color shifting.... great.  Now, I have

--color=never is supposed to stop ls from ever using colour.

> This gets me using vim and pointing to an initialization file for it
> ".vimrc".  so what do I put in this .vimrc to STOP the damn color shifting
> in vi?????  I have read the info about "syntax"  and tried 
> 
> Syntax off
> Set syntax=off
> Set syntax off

Assuming those weren't typos three in a row, your problem is the capital
letters.  Syntax off (no equals sign) won't work with a capital S.  It's
just "syntax off" in all lower case, no use of set at all.

If you use a capital letter, you'll get a warning about an invalid command
in the rc file, but then it will clear screen and enter vim anyway, using
colour.

> I have looked all through the "dircolors" command... but this doesn't seem
> to apply, and/or doesn't work.... Damn, I have waded through the hundreds of

That command applies only to ls.  The only thing remotely close to a
"global" colour scheme setting program is setterm, and that will be
overridden by any application that sets its own colours.

> Ultimately, I would LOVE to be able to govern the color of my screen so I
> could do what I so easily do on SCO, change my foreground and background
> based on my PFDIR... live, or dev, etc.   

man setterm and look at the foreground and background options.  Just bear
in mind that if you access different fP binaries independantly, you'll want
to create different aliases for them.  For instance (and obviously I'm
using colours here but you can use black and white:

/appl/fp/rclerk !*; setterm -foreground yellow -background blue -bold

The !* is tcsh syntax and just means "use the rest of the arguments on the
command line here".  I don't think I've ever tried this in bash.

> Can anyone help.  I'll even pay. :-)  Seriously, I will pay your consulting
> fee to educate me about this stuff.  I know, and have this nagging belief
> that someone is going to write... you idiot, just type:
> 
> Color off
> AT the prompt or something incredibly stupid like that.... I don't care.
> Send me the pain.  I simply have to solve this... since I am doing lots of
> work on Linux these days, and particularly this Debian version  "ubuntu".

Well, if you didn't typo above, it comes down to a matter of case.  VIM is
case sensitive in its commands.  I tested it before writing this, using vim
version 6.1.

Sounds like one of those imfamous 8hr bug hunts that comes down to one
character.  :/  Been there, my friend.

Let me know if any/all of this helps.

mark->
-- 
"Moral cowardice will surely be written as the cause on the death
certificate of what used to be Western Civilization." --James P. Hogan