Is it possible to activate colors, e.g. for PS1 or git output for a terminal that is only connected over serial? What options have to be activated?
Related
I'm doing some experiments and while I do it I have to turn a board off and on frequently (a program doesn't get killed properly probably with unclosed socket .. I installed signal handler and it worked and now it doesn't..) . Every time I turn on the board, I start vnc window (it starts xfce4 ) and have to open terminals in specific location. Is there any setup method through which the terminals are open automatically in specific locations? Or further with specific number of tabs? (I know how to give xwindow location and size : xwininfo -all. and use -geometry 1000x1000+300+300 for example).
From what I understand, you could add commands to the application autostart menu in Settings > Session and startup and give the command the working directory as an option as follows:
xfce4-terminal --default-working-directory="/home/$USER/Desktop"
The different options available are:
OPTIONS
Option Summary
Here is a summary of all the options, grouped by type. Explanations are in the following sections.
General Options
-h, --help; -V, --version; --disable-server; --color-table; --default-display=display;
--default-working-directory=directory
Window or Tab Separators
--tab; --window
Tab Options
-x, --execute; -e, --command=command; -T, --title=title; --dynamic-title-mode=mode;
--initial-title=title; --working-directory=directory; -H, --hold; --active-tab;
--color-text=color; --color-bg=color
Window Options
--display=display; --drop-down; --geometry=geometry; --role=role; --startup-id=string; -I,
--icon=icon; --fullscreen; --maximize; --minimize; --show-menubar, --hide-menubar;
--show-borders, --hide-borders; --show-toolbar, --hide-toolbar; --show-scrollbar,
--hide-scrollbar; --font=font; --zoom=zoom
Refer to the man page for more settings related to tabs and windows.
man xfce4-terminal
When I have some operations on Mac Terminal, the user's input and the shell's output have the same color
When I have a lot of operations and I want to look back in the history, it is difficult because all the lines of the user's input and shell's output mix together.
I want to specify a different color for the user's input text. How can I do this in macOS Terminal?
System version: macOS High Sierra 10.13.1
Software: Terminal
In ~/.bash_profile add this line:
export PS1='\[\e[1;31m\]\h\[\e[0m\]:\[\e[1;34m\]\w\[\e[0m\]\$ '
It will set colors of the prompt. You can read some more about this here.
You can also change some colors in Terminal -> Preferences... -> Profiles -> Text.
I'm trying to get 256 colors in the fantastic ConEmu-Maximus5 console.
Update: Now it only shows 8 colors. I know because '$tput colors' output is '8'
I have followed the instructions and activated:
TrueMod (24-bit color) support
Inject ConEmuHk
ANSI x3.64 / xterm 256 colors
I don't understand what to do with 'check off whether the buffer / slide.'
I'm in windows 7.
I start ConEmu with a custom direct link, so it loads cygwin bash file.
"C:\Program Files\ConEmu\ConEmu64.exe" /cmd ""C:\cygwin\bin\bash.exe" --login -i"
In my bashrc profile I have -> export TERM=cygwin
This is my custom command prompt:
function prompt {
local RED="\[\033[0;31m\]"
local GREEN="\[\033[0;32m\]"
local COOLRED="\e[38;5;173m"
local COOLGREEN="\e[38;5;113m"
PS1="$COOLRED\u#\h $LIGHT_COOLGREEN\$PWD \[\e[0m\] > "
}
prompt
The value of ConEmuANSI in ON, by the way.
I have some screen shots:
As you can see the command prompt looks very extravagant because it doesn't like the 256 color settings. If i substitute the variables COOLRED and COOLGREEN with RED and GREEN, then it looks ok, but it's not 256 colors.
More screenshots of the settings:
And the last sceen shot it's cygwin's mintty. Everything is ok there. Full 256 color supported. It's a shame mintty doesn't have tabs. That's mostly the reason why I'm trying to move to ConEmu.
Thank you very much for helping!!!
Bash does not send ANSI sequences to console. It tries to process them itself. And, because *nix terminal is generally only 8-color (not taking into account 256-color mode), bash uses 8-color palette instead of 16-color palette which is common to Windows terminal.
I think, 256-colors works in mintty because _isatty returns zero in that terminal. But it returns non zero value under ConEmu. May be in future builds I solve this puzzle (how to create real terminal with PTY features for some applications).
As for the question
You have no need in 256-colors In fact. To redefine prompt palette you may use "Extend foreground colors with background" feature. In breaf - set up colors 16, 17, etc. in ConEmu, set prompt background in bash to #5 (configurable in ConEmu), and voila.
There was a small bug in ConEmu "Extend..." processing. Use build 121016 or later.
PS1="\e[30;45m\u#\h \e[34;45m$PWD \[\e[0m\] > "
Following info does not match the question, but may be useful
Current version does not support 256-color mode in 'whole' console buffer (limitation, yes, removing it in plans).
So, you can go 2 ways
totally disable scrollback buffer (many ways, for example "cmd -cur_console:h0")
work in the bottom of the scroll-buffer.
I also couldn't get 256 color support to work (the colors would show up, but they looked the same as the 16-color palette). I switched to the "xterm" color scheme and now it works in native Windows executables (such as Python) but not in anything that uses Cygwin. Cygwin appears to have terminal-escape-sequence processing that you can't turn off, which defeats the ConEmuHk injection.
This is documented on the ConEmu wiki, here.
I had this weird problem and the weird solution and somehow it works. and don't know if this is with others too, just some info-sharing in case this shall be helpful.
I like colouring my consoles and like to utilize the full real 256 bits of RGB colouring.
After confuguring as in the conemu/CMDer (i used the forked one) instruction. my 256bit coloring test looked like this.. After mucking around a bit and testing with my bash 256bit capability. i.e running this command:
for i in {1..16384}; do echo -en "\e[38;5;${i}mTest";done
*note supposed to be {1..256}, but i had to force it for a longer colour prints, so just took a longer random number..
giving the result:
But running some 2-3 times, i saw this clean gray shade suddenly
and it worked then on..
weird but i got this working. Could it be that CMDer is somehow not using the full 256 bit because of optimizing reason and it get triggered when it is kicked in??,
PS: my CMDer cmd for the console:
-cur_console:fp -cur_console:d:"C:\WS":P:"<Cobalt>":t:"test":C:"C:\Arbeit\tools\Iconka-Buddy-Ninja.ico" set "PATH=%ConEmuDrive%\Program Files\Git\usr\bin;%PATH%" & "%ConEmuDrive%\Program Files\Git\git-bash.exe" --no-cd --command=%ConEmuBaseDirShort%\conemu-msys2-64.exe /usr/bin/bash.exe -l -i
local COOLRED="\e[38;5;173m"
local COOLGREEN="\e[38;5;113m"
Those \es are probably from an e.g. C printf string. You don't want them in a shell script. Stick with the original \033 notation. Also you are missing the closing \]. These lines should now read
local COOLRED="\[\033[38;5;173m\]"
local COOLGREEN="\[\033[38;5;113m\]"
I'm using OSX snow leopard, for the record.
When I use emacs straight from terminal, I have a color set (e.g. for c/c++) that I'm very happy with---green on black, red comments, colored key words... etc etc. Some of this is set in my 'terminal preferences', and some is in my ~/.emacs file (see below). When I run emacs from screen, the basic color-scheme is the same (green on black), but the coloring is different (e.g. comment characters are red, but not the entire comments) -- and really annoying.
Any help would be appreciated!
In my '.emacs' file (this stops working in gnu-screen emacs):
(global-font-lock-mode t)
(custom-set-faces
'(font-lock-comment-face
((((class color) (background light))
:foreground "tomato")
)))
In my '.screenrc' file:
shell -$SHELL # colors still don't work without this
#term xterm-256color # using this doesn't fix the colors (suggested on some forums)
altscreen on
startup_message off
I thought that the command 'shell -$SHELL' in my .screenrc file made the command prompt in screen the same as the default --- it does make my command line say 'computername:/DIR/ username$' instead of just 'bash-3.2$'
=================================================================
Solution: Thanks to Greg E.
I needed to set my terminal emulator in screen to match that of my normal shell. To do this, I added
export TERM='xterm-color'
to ~/.bash_profile
For some reason, 'term xterm-color' in the '~/.screenrc' file didn't work.
My suspicion is that, while your terminal may be compiled with support for more than the standard 16 colors, your particular version of GNU screen may not be. I'm not very familiar with OSX, but on Linux I'd check whether the output of tput colors differs between a plain terminal and one running screen (I'd expect there to be some OSX equivalent if tput is not available). If it does, you may need to install (or manually compile) a different build of screen that includes support for additional colors (normally, 256 is the maximum, but 88 is also common, while 16 is the default minimum).
Edit: Ultimately, the correct solution proved to be manually setting the $TERM environment variable (see comments below).
I'm having trouble getting tmux to display lines for borders. They are being created with x and q. It's a debian squeeze server and the locale is set to en_US UTF8. I also tried adding
# instructs tmux to expect UTF-8 sequences
setw -g utf8 on
set -g status-utf8 on
lines to .tmux.conf. Nothing seems to work. I'm not sure if it's a locale issue or not. It displays correctly on other servers, but not the debian. I appreciate any tips you could offer! Thanks...
I had the same problem with PuTTY and Windows 8 when connecting to tmux running on a Debian Squeeze machine. Even when setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) I didn't get the correct line drawing.
Setting the Remote character set to "Use font encoding" did the trick for me.
There is some mismatch between your terminal emulator and the terminfo database entry being used by tmux (the one named by the TERM environment variable when you start/attach to a tmux server).
Per the VT100 User Guide, Table 3-9: Special Graphics Characters, when the “special graphics set” is selected, x is used to draw the “Vertical bar” and q is used to draw “Horizontal line - Scan 5”.
Under terminfo, the VT100 special graphics characters are available as a part of the Alternate Character Set functionality; see the “Line Graphics” section of the terminfo(5) man page.
Probably (on your Debian server) the effective terminfo database entry indicates that ACS is available, but your terminal emulator is not actually responding to the specified control sequences.
The tmux CHANGES file indicates that some terminal emulators (e.g. Putty) do not respect the ACS control sequences when they are in UTF-8 mode. Thus, tmux 1.4 has a change that makes it always use UTF-8 characters instead of ACS sequences when the attaching client specifies that it can handle UTF-8 (i.e. when attaching, -u was given or UTF-8 is present in LC_ALL, LC_CTYPE or LANG; the utf8 window option is about what tmux should expect from the programs it runs, not what it can send to the attached client).
Debian “squeeze” only includes tmux 1.3, so your tmux probably does not have the “prefer UTF-8 line drawing” feature (unless it pulls from a backports source).
If you can not fix your terminal emulator nor upgrade to at least tmux 1.4, then you might be able to use tmux’s terminal-overrides option to unset the ACS-related capabilities so that tmux will fall back to ASCII line drawing. In your .tmux.conf (on the Debian system):
set-option -ga terminal-overrides ',*:enacs#:smacs#:rmacs#:acsc#'
Try setting the character set to "UTF-8" and "Use Unicode line drawing code points" under Window -> Translation in your putty settings.
I had the same problem with Putty when launching tmux on Linux 12.04 machine. Even setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) didn't solve the problem.
Launching tmux with -u option did the trick (tmux -u)
If you have Putty 0.73 or higher open settings, expand Window category, then select Translation. Check 'Enable VT100 line drawing even in UTF-8 mode':
I ran thru the gamut of suggestions including:
confirming locale and UTF-8 setting in PuTTY
exporting NCURSES_NO_UT8_ACS=1
manually trying various fonts and PuTTY translation selections
Above did not work. Dialog displays showed qqqq... and xxxx with various corner characters.
Changing all dialog calls to include --ascii-lines was an option but it would involve a lot of script changes.
Best recommendation was to change the Remote Character Set to Use font encoding.
PuTTY Change Settings --> Window --> Translation --> Remote Character Set --> Use font encoding
Left all other PuTTY settings default.
I changed the setting in Putty for terminal to Latin-1 and that seemed to fix the problem.
If you are using KiTTY there is a check box under Windows -> Translation tab, that is called "Allow ACS line drawing in UTF". It needs to be checked:
For me the issue was I forgot to make a locale.conf file when I setup this Arch Linux box. Below line fixed the issue, substitute your own language. A reboot was not required for me.
echo "LANG=en_US.UTF-8" > /etc/locale.conf
under windows/ putty the font you use has to have the characters for it to display
set translation "UTF-8" and "Use Unicode line drawing code points" and font to "courier-new" and most of those problems go away
It seems the font choice is a confusing factor here, to wit:
Lucida sans doesn't display UTF-8 line drawing, only - + | (pipe)
substitution
Courier New Bold does horizontal lines but |
substitution for vertical
Courier New Normal does 'em all.