12

My local Linux machine has coloured terminal output like this;

enter image description here

When I SSH to a pfSense/BSD box it changes the colours like this;

enter image description here

Even when I SSH from to a machine that doesn't have a coloured local terminal output, and SSH from there to this pfSense/FreeBSD box it enables coloured output, and starts producing unwanted coloured output/

Is there something I can change locally so that when I SSH to the pfSense box from either my local machine or via an intermediary machine, my client will ignore the remote colour settings. Ideally I want to stay in black and white, two tone standard background and text colour only?

4
  • What terminal application are you using?
    – gertvdijk
    Dec 20, 2012 at 11:28
  • 1
    Here I am running Mint Linux 13, so it's Xfce Terminal Emulator 0.4.8.
    – jwbensley
    Dec 20, 2012 at 11:32
  • 1
    I know this isn't what you are asking for, but have you considered changing your terminal settings to white [or light gray] text on a black background? That is the basic color scheme that most things are designed to work with. Or you could change your prompt settings on the remote machine (probably in .bash_profile) to have better colors or no colors at all.
    – Random832
    Dec 20, 2012 at 15:57
  • 1
    Normally I do something like TERM=xterm-mono ssh user@host to get that setting in the remote environment.
    – ott--
    Dec 20, 2012 at 17:11

6 Answers 6

8

Colours in your terminal appear because the tty sends ANSI-encoded control sequences to tell your terminal to change colours. Some, if not most terminal application can be configured to ignore this and just display all text in one colour.

In xterm, you can use the -cm option. For Konsole, one can change the mapping of all colours to the same. Your XFCE terminal application may have similar options.

2
  • This answer may help in some cases, but it is not really an answer. As mentioned "Colours in your terminal appear because the tty sends ANSI-encoded control sequences to tell your terminal to change colours". As SSH may provide TTY, it should also be possible for SSH to ignore colors. Any idea how this is done?
    – patrik
    Jun 3, 2019 at 14:10
  • 2
    SSH is not designed to interfere with the data over the tty, really. SSH sets up a channel on which you can run it, I don't think it should ever involve in altering data over that channel. It does, however, provides context and metadata, such as which environment variables are passed from client to server during setup time of such a channel.
    – gertvdijk
    Jun 3, 2019 at 23:13
8

Changing the TERM variable to some entry that is compatible but doesn't have colour support might work. Like:

TERM=xterm-old

Basically, you need a TERM known by the FreeBSD system termcap or terminfo database for which TERM=the-term tput colors doesn't return a positive number, and for GNU ls, one for which dircolors -p | grep -x 'TERM the-term' returns nothing. It may still not work for applications that output colour escape sequences regardless of whether the terminal claims to support it or not.

Alternatively, you could use GNU screen to disable colors, like (zsh syntax):

screen -c =(printf %s\\n "termcapinfo * 'AF=\E[1m:AB=\E[7m'") ssh ...

That would enable bold for every attempt to set the foreground colour and reverse for every attempt to set the background one.

I think it all boils down to the fact that FreeBSD assumes that the terminal background is black (or at least dark). Where you using xterm instead of xfce-terminal, you could dynamically change the background and foreground colour and/or the individual colours to set different colour profiles. That is done through escape sequences, but you can also use the xtermcontrol command that makes it easier.

6
  • Tried that - doesn't work for me. export TERM=vt100 preceding ls --color still shows colorized output.
    – gertvdijk
    Dec 20, 2012 at 12:22
  • @gertvdijk Good point. It seem there's a bug in GNU ls which by default hard codes vt100 as being a terminal with colour support. I've changed that do xterm-old which doesn't have that problem but might not have a terminfo entry on FreeBSD. Dec 20, 2012 at 12:28
  • Well, it doesn't prevent other programs from outputting colour as well - i.e. byobu. I'm on Ubuntu 12.04 btw.
    – gertvdijk
    Dec 20, 2012 at 12:29
  • 1
    @gertvdijk. Like I said. It only works for well behaved programs that use $TERM and the termcap/terminfo databases (via curses or other terminal APIs) instead of hardcoding the escape sequences. Dec 20, 2012 at 13:07
  • what can i use to remove all escape sequences that can change terminal state after EOF? Aug 11, 2015 at 20:10
2

In case you don't want to modify your ~/.bashrc which I'm sure contain something like export PS2=.....+colors...... :

On the linux Console, try either TERM=linux-m1b or TERM=linux-m2 to get monochrome as "Gray/White/Black and Dim" for linux-m1b or "Green/White/Black and Blue" (vintage!) for linux-m2 ...

With Putty (there is a port for Mac users), use TERM=putty-m1b and TERM=putty-m2 instead ...

This will do exactly what you need but: You'll need a recent terminfo database for that or get it from there if necessary: wget http://canal.chez.com/linux.ti ; tic -x linux.ti

Alex. PS: xterm-mono seems not to exist anymore.

2

Type the following command to remove it:

$ ls --color=none

or use unalias to remove it:

$ unalias ls
7
  • 1
    Isn't that just for the ls commad though?
    – jwbensley
    Dec 20, 2012 at 11:31
  • ls is aliased to "ls --color=tty"
    – Len
    Dec 20, 2012 at 11:34
  • Yes. I know. But all my terminal output is coloured output, not just the ls command, so as per my previous comment: isn't that just going to stop ls producing coloured output, everything else will still be coloured though?
    – jwbensley
    Dec 20, 2012 at 11:35
  • yes only the ls portion
    – Len
    Dec 20, 2012 at 11:39
  • 1
    are you using xterm? xterm -cm
    – Len
    Dec 20, 2012 at 11:43
0

You should be able to convince your terminal emulator and environment that it cannot support colors in the first place, presuming your GNU/Linux system is not ignoring the rules:

unset LS_COLORS
TERM=xterm-mono
export TERM

Try using TERM=vt100 or TERM=xterm-mono in something like htop and you should immediately see the difference.

You could also quickly test by trying to toggle colors in top by pressing lowercase z.


Alternately, by combining some other contributors methods, you could get a list of "no-color" terminal definitions (-1) and pick one:

$ find /lib/terminfo -type f -exec sh -c 'for fx do T=`basename "$fx"` ;echo -n "$T ";TERM=$T tput colors ;done' find-sh {} + | sort -V | grep '\-1'
dumb -1
mach -1
mach-bold -1
mach-gnu -1
rxvt-basic -1
sun -1
vt52 -1
vt100 -1
vt102 -1
vt220 -1
xterm-mono -1
xterm-r5 -1
xterm-r6 -1
4
  • That won't work, because dircolors -p uses globs, e.g., xterm* which match anything usable in /lib/terminfo. Oct 17, 2021 at 14:09
  • Eh? It seems to work on this end. But if anyone would know, then you would. I guess I just got lucky. Is there a recommended way around it?
    – Kajukenbo
    Oct 18, 2021 at 15:15
  • 1
    Actually "vt220" looks promising (though function-keys may be a problem). Oct 18, 2021 at 23:37
  • I wonder if it appears to work on this end because I "unset LS_COLORS" out of habit? Either way, I will take your lead and default to TERM=vt220 now and see how it goes.
    – Kajukenbo
    Oct 20, 2021 at 3:10
-2

First, check your default alias:

alias

alias ls-'ls --color=auto

If the doesn't work and you need a quick workaround. Try this ls and awk pipe:

vi /usr/local/bin/list
#!/bin/bash
ls $1
exit

set the perms 744.
One safe place for this would be /usr/local/bin Make sure your PATH includes /usr/local/bin.

Again use discretion.

One thing… the colors are meant to flag directories… turning off the ls="ls --color=auto" leaves only names… ls -aF or ls -F will append the directory names with /. So I would suggest that you be aware. You could alias ls="ls -aF" or alias ls="ls -F".

3
  • 2
    How does this answer provide an answer to the original question?
    – jwbensley
    Jan 25, 2017 at 19:05
  • Welcome to Stack Overflow! I recommend you take the tour. Jan 25, 2017 at 19:24
  • To the parts that this doesn't duplicate existing answers, it is simply wrong (ranging from robustness problems to outright invalid syntax).
    – tripleee
    Jan 23 at 11:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.