Fish shell is not displaying symbols properly in gnome-terminal (Ubuntu 17.04).
Fish prompt symbol
Staging index status
-
locale output
LANG=en_IN
LANGUAGE=en_IN:en
LC_CTYPE=en_IN
LC_NUMERIC="en_IN"
LC_TIME="en_IN"
LC_COLLATE="en_IN"
LC_MONETARY="en_IN"
LC_MESSAGES="en_IN"
LC_PAPER="en_IN"
LC_NAME="en_IN"
LC_ADDRESS="en_IN"
LC_TELEPHONE="en_IN"
LC_MEASUREMENT="en_IN"
LC_IDENTIFICATION="en_IN"
LC_ALL=
You should set your locale to a UTF-8-containing locale (ie en_IN.UTF-8). Ubuntu normally does this by default, so perhaps you should run sudo update-locale LANG=en_IN.UTF-8 LANGUAGE="en_IN:en".
If that still fails to work, in the GNOME Terminal profile settings, under the compatibility tab, try setting "Ambiguous-width characters" to "Wide" instead of "Narrow".
Related
I typed on my terminal the following command :
export BACKEND_URL="<confidential>"
. Apparently it was working, but when I turned off my computer and turned on again, I realized that this env var named BACKEND_URL It was not saved anymore. Why this happened ?
First of all:
This question would better fit the Unix&Linux StackExchange site than this web site.
However:
By typing "BACKEND_URL="<confidential>"" you set a variable which is valid for the currently running shell (terminal window) only.
If you close the terminal window, the variable is gone. The variable is also not valid for programs started from that terminal window.
If you add export (as you did), the variable is also valid for programs started from that terminal window.
However, still it is not valid for other terminal windows and if you close the teminal window, it will be gone.
When using one of the standard shells, you can add variables to the .profile file in your home directory.
When you are using bash, you can also add variables to the .bashrc file in your home directory.
i have been using cygwin/X for many years and have not had any major problems, until the upgrade of xinit to version 1.3.x, it breaks everything without any warning at all. people wonder why open source gets such a bad reputation, it's this kind of blindsiding that does it...
anyway, prior to xinit 1.3.x i started Xwin via the Xwin icon. i could then start xterm (or emacs or any X application) using run.exe which i would pin to the taskbar. my command line is as such:
D:\cygwin\bin\run.exe -p /bin bash ~/scripts/xterm.sh
my xterm.sh is as follows:
export DISPLAY=127.0.0.1:0.0
xterm &
exit
this has worked like a charm for YEARS, now it doesn't do anything.
even doing this in a windows cmd:
set DISPLAY=127.0.0.1:0.0
d:\cygwin\bin\run.exe -p /usr/X11R6/bin xterm
doesn't work anymore...
does anyone know how to start an Xwin application (xterm, emacs ...) via the dos command line ...
Try to set DISPLAY to :0.0 (not 127.0.0.1:0.0). Source.
I installed Antergos (easy version of Arch) with the Japanese environment.
But I wanted to chaned the language to English, so I reffer the wiki article then run some commands after uncomment #en_US.UTF-8 UTF-8 in /etc/locale.gen and edit /etc/locale.conf into following:
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=
The problem starts from here.
I restarted my computer and found that gnome-terminal doesn't work.
I substituted eshell on Emacs and run gnome-terminal command, then got error messages:
(process:1202): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 8
The output of locale command is following:
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=ja_JP.utf8
LC_TIME=ja_JP.utf8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=ja_JP.utf8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=ja_JP.utf8
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=ja_JP.utf8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
What changes some part of locale setting into Japanese? Or other reasons which terminate gnome-terminal exist?
I have tried solutions sugestted here https://bbs.archlinux.org/viewtopic.php?id=180103 .
Thank you.
I had the same problem some time ago. I fixed my locale config running this command
sudo localedef -f UTF-8 -i en_US en_US.UTF-8
The meaning of status code 8 is documented on gnome's website here:
The environment that gnome-terminal-server is started with does not
correctly set the locale to a UTF-8 locale. Consult your
distribution's documentation on how to fix this. Note that is it not
relevant to check the locale settings from a different terminal (e.g.
xterm); what counts is the environment that the session dbus-daemon
passes to the processes it starts.
So you're right, this is probably due to locale settings. I don't quite understand all the details, but if I set ~/.xinitrc to exec gnome-session and then run startx, I get a similar error to yours.
However, if instead of running startx, I start the gdm display manager (via systemctl start gdm.service on Arch), I can spawn a gnome-terminal correctly. So if you're okay with using gdm, that may be a solution. Lightdm also works, though SLiM doesn't (from my experience).
In the past, I also had to install the vte3 package for gnome-terminal to work, so make sure that's installed as well. And FWIW, sudo gnome-terminal seems to always work.
Did you think to regenerate your locales after you had edited your /etc/locale.gen file ?
locale-gen
I think in your explanation you mixed the /etc/locale.gen and the /etc/locale.conf files. Be sure you edited the correct file with the correct values.
Ok this is how I solved it;
sudo locale-gen --purge --no-archive
Then; sudo update-initramfs -u
Nothing with locale worked for me. Once changed back the default python version (3.5 on ubuntu16), terminal worked just fine.
cygwin64 had been running great on my Windows 7 system for several months. After rebooting this morning, it appeared to be inexplicably broken. When I started a new mintty session, rather than presenting a window with my familiar bash prompt, I got a blank window entitled -sh.exe. Sure enough, despite the lack of any sort of prompt, it was a shell window. ls, pwd, cd, and other commands worked, but my environment was a mess. Aside from the lack of a prompt, my home directory, path, and other things were messed up.
I tried the normal things. I reran cygwin setup to no avail. I completely uninstalled and reinstalled cygwin, again with no discernible effect. I rebooted a number of times during all these tries. What could cause cygwin to suddenly begin behaving so badly?
I had similar issues after installing IBM InfoSphere DataStage, which causes Cygwin to misbehave because it is setting several Windows environment that are inherited by Cygwin, and are crucial to Mintty and the shell. These variables are: SHELL, TERM, TERMCAP, and TERMINFO.
I modified my Mintty shortcut to contain the following target, and this fixed the issues:
C:\cygwin\bin\mintty.exe /bin/env -u SHELL -u TERMCAP -u TERMINFO - TERM=xterm-256color HOME=/home/username /bin/bash -i -l
The -u options are unsetting those variables, and then I'm explicitly setting TERM and HOME (make sure to use your home directory instead of /home/username).
I also had to copy my ~/.minttyrc file to /etc/minttyrc so that mintty would see it.
After digging around, I noticed that the sh.exe that was running was not in /cygwin64/bin, but was instead in \Program Files (x86)\MKS Toolkit. I did not recall installing MKS, but the date on this directory was from the previous day. The only thing I'd recently installed was the IBM InfoSphere DataStage client. It turns out, InfoSphere not only installs the MKS Toolkit, it prepends it to a number of environment variables, totally hosing cygwin.
I am running a standard installation of OpenSuse 42.3. I ssh to the Opensuse machine via my MacOS computer. When I use vim to view files in the terminal window the syntax highlighting is pleasant to look at. I also have a Docker image of a stock installation of OpenSuse 42.3 installed on my OpenSuse machine. If I boot up the container and open a python file with vim within the container, the syntax highlighting looks different. I did a diff on the contents of the /usr/share/vim/vim74/syntax/python.vim, and there were no differences between the syntax file that is being used on the OpenSuse host and the OpenSuse container.
Below on the left is what I see when I ssh from my Mac to the OpenSuse machine and open a python file. On the right is what I see when I start the docker container ( still in the same terminal window that I started for the image on the left).
Shouldn't the display on the terminal window of the syntax highlighted file be the same if the vim syntax files are the same?
The highlighting in the terminal can depend on the number of available colors. Some colorschemes have separate branches of color definitions depending on how many are available. You can check for yourself via
:set t_Co?
You probably get 256 for TERM=xterm-256color and only 16 for TERM=xterm.
Though you can just force :set t_Co=256 and reload your colorscheme, it's better to fix the root cause, i.e. the wrong TERM value.