I have encountered a strange problem on one of our machines.
It is a fresh install of Debian Squeeze, with Postgres 8.4.10.
I have a few localizations installed on the machine, locale -a gives this:
C
en_US
en_US.iso88591
en_US.utf8
POSIX
swedish
sv_SE
sv_SE.iso88591
sv_SE.utf8
In the regular linux console I can use swedish localization (åäö works), but when I enter the psql console I can't use localized characters. Doesn't matter how I configure my terminal (tried just about every encoding I can think of).
The database itself works fine, I can input localized chars by making a SQL file and keep the inserts there. It's just no the most efficient way of doing it ;-)
Haven't run into this problem before, and I've installed quite a few machines. Does anyone have any idea of what could possibly be the cause of this?
I believe you're experiencing the problem explained in this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442
Summary: due to a licensing issue, psql is now linked to libedit instead of libreadline, and unfortunately libedit is broken/incomplete with regard to accented characters.
According to the report, a work-around is to launch psql with:
LD_PRELOAD=/lib/libreadline.so.5 psql
or upgrade the postgresql-common package to version 114 or higher. Since it's not in the stable branch, the easiest way may be to switch to backports:
# aptitude -t squeeze-backports install postgresql-common
Check the database encoding with \l then check the client encoding:
=> show client_encoding;
client_encoding
-----------------
UTF8
(1 row)
If they do not match then change the client encoding to that of the database:
set client_encoding=iso88591;
Related
I'm using the Atom editor. Yesterday, if I typed:
sudo atom . it opened the current directory as root
sudo atom it opened Atom with whatever I last had open as root
Today if I run either of those commands nothing happens. The editor doesn't open and there are no error messages.
These terminal commands worked yesterday on these exact same files, today they do not.
How can I fix this?
Why is this happening?
If I have not provided enough information it's because I don't know what info one would need to have a fuller explanation of my circumstance. Let me know what I should add I'll happily edit this question to provide it.
Atom : 1.13.0
Electron: 1.3.13
Chrome : 52.0.2743.82
Node : 6.5.0
Ubuntu 14.04 LTS
Elementary OS Freya (64-bit)
After updating Atom text editor it seems I require to run --no-sandbox flag but after a while it becomes boring so I wrote a simple BASH script to be doing this for me:
eval "atom --no-sandbox flag"
just save this in a common directory that you frequently use and type ./atom_text_editor.sh in the terminal to deploy(Depending on the name you choose for your script)
A recommendation, when working on linux avoid using sudo or su instrucctions, they are intended to execute privileged instructions like system configurations. It might be related to permissions, execute ls -al and verify that the owner/group of yor files is root, if not, then check if "others" have read permission, if not, then thats is the problem.
Be aware running atom with sudo is not recommended.
I've had this problem for a few days, I installed atom using snap (on ubuntu 18.04) a few weeks ago, back then it worked perfectly, but the last few days if i ran 'sudo atom' nothing would happen at all, reinstalled it using snap, still didn't work, removed settings, still didn't work.
I ended up installing atom using the apt packagage manager and now it works. I used this guide: https://codeforgeek.com/install-atom-editor-ubuntu-14-04/
Furthermore when running atom with sudo it should be ran with the --no-sandbox flag.
Conclusion: seems to be a problem with atom when installed using snap.
I'm running OS X 10.10.5. I'm getting an error trying to open a terminal:
tput: unknown terminal "xterm-256color"
This is obviously a missing termcap entry.
$ port list ncurses
ncurses #6.0 devel/ncurses
Any ideas how to install 'ncurses-term' on OS X?
$ sudo port install ncurses-term
Password:
Error: Port ncurses-term not found
The problem was with an Anaconda package:
https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/XKMFYqM12Vg
It appears there is some problem with an earlier version of the ncurses package that interferes with terminfo
conda install -c r ncurses
Notwithstanding the existence of bloated/monolithic packages on Linux, the package maintainers for ncurses packages often split up the 7Mb of terminfo into "base" and "term" chunks (and separate it from the library). The MacPorts maintainer for ncurses has not done this. The terminal database is part of the "ncurses" package. For instance, I see this from
port contents ncurses#6.0_0+universal
under /opt:
/opt/local/share/terminfo/73/screen.xterm-256color
Also there is a system (non-port) copy here:
/usr/share/terminfo/78/xterm-256color
Applications linked with ncurses will generally use one or the other, depending on whether they are linked with the port- or system-library. However, ncurses can be told to look some other place by setting the TERMINFO variable. If you happen to have copied some customization from another machine into your .bashrc, that could have set TERMINFO.
By itself, tput gives no clue where it is looking for a terminal entry. You can check the output from env to see if TERMINFO is set. The infocmp utility can show where it looks (since late 2011), using the -D option, e.g.,
$ infocmp -D
/usr/local/ncurses/share/terminfo
/usr/share/terminfo
/opt/local/share/terminfo
By the way, OSX does not (barring some specialized ports) use termcap as such. It uses terminfo, as part of some given release of ncurses (see for example the manual page for tgetent).
Recently tried using the following startscript here:
http://dev.bukkit.org/bukkit-plugins/linux-server-startscript-menu/
After installing dos2unix, it says it is installed and using the latest version. I then use the command "dos2unix startserver.sh" and I prompted with the message: "dos2unix: converting file startserver.sh to UNIX format ..." and then it returns to the next blank command line. Problem is there is nothing actually starting the script or I am missing something. I have tried talking to the owner of this script and he helped me to this point, but is unsure what to do next. He says he uses debian and is less familiar with CentOS and so I am posting here.
Here is my script that has been edited according to my server. The most important change I made is SCRIPTUPDATE="0" (so it doesn't update)
Please keep in mind that I am very new to linux and any operating systems in general.
The dos2unix command converts the newline characters in a file from dos format to unix format. This is just for cleaning up a file that may have problems (e.g., from a bad ftp transfer).
Try running the ./startserver.sh command again, now that the file has been cleansed.
I want to check in a script if PostgreSQL is installed or not on Linux and print the result.
Any suggestions on how to do the check?
What about trying the which command?
If you were to run which psql and Postgres is not installed there appears to be no output. You just get the terminal prompt ready to accept another command:
> which psql
>
But if Postgres is installed you'll get a response with the path to the location of the Postgres install:
> which psql
/opt/boxen/homebrew/bin/psql
Looking at man which there also appears to be an option that could help you out:
-s No output, just return 0 if any of the executables are found, or
1 if none are found.
So it seems like as long as whatever scripting language you're using can can execute a terminal command you could send which -s psql and use the return value to determine if Postgres is installed. From there you can print that result however you like.
I do have postgres installed on my machine so I run the following
> which -s psql
> echo $?
0
which tells me that the command returned 0, indicating that the Postgres executable was found on my machine.
Here's the information about using echo $?
We can simply write:
psql --version
output show like:
psql (PostgreSQL) 11.5 (Ubuntu 11.5-1.pgdg18.04+1)
If it is debian based.
aptitude show postgresql | grep State
But I guess you can just try to launch it with some flag like --version, that simply prints some info and exits.
Updated using "service postgres status". Try:
service postgres status
if [ "$?" -gt "0" ]; then
echo "Not installed".
else
echo "Intalled"
fi
There is no single simple way to do it, because PostgreSQL might be installed and set up in many different ways:
Installed from source in a user home directory
Installed from source into /opt or /usr/local, manually started or started by an init script
Installed from distributor rpm / deb packages and started via init script
Installed from 3rd party rpm / deb packages and started via init script
Installed from packages but not set to start
Client installed, connecting to a server on a different computer
Installed and running but not on the default PATH or default port
You can't rely on psql being on the PATH. You can't rely on there being only one psql on the system (multiple versions might be installed in different ways). You can't do it based on port, as there's no guarantee it's on port 5432, or that there aren't multiple versions.
Prompt the user and ask them.
There is no straightforward way to do this. All you can do is check with the package manager (rpm, dpkg) or probe some likely locations for the files you want. Or you could try to connect to a likely port (5432) and see if you get a PostgreSQL protocol response. But none of this is going to be very robust. You might want to review your requirements.
If you are running Debian Linux (or derivative) and if you have a postive return with > which psql, then simply type psql -V (capital "V") and you will get a return like: psql (PostgreSQL) 9.4.8
And if everything else fails from these great choice of answers, you can always use "find" like this. Or you may need to use sudo
If you are root, just type $$> find / -name 'postgres'
If you are a user, you will need sudo priv's to run it through all the directories
I run it this way, from the / base to find the whole path that the element is found in. This will return any files or directories with the "postgres" in it.
You could do the same thing looking for the pg_hba.conf or postgresql.conf files also.
For many years I used the command:
ps aux | grep postgres
On one hand it is useful (for any process) and gives useful info (but from process POV). But on the other hand it is for checking if the server you know, you already installed is running.
At some point I found this tutorial, where the usage of the locate command is shown. It looks like this command is much more to the point for this case.
aptitude show postgresql | grep Version worked for me
Go to bin directory of postgres db such as /opt/postgresql/bin & run below command :
[...bin]# ./psql --version
psql (PostgreSQL) 9.0.4
Here you go . .
You may also check in /opt mount in following path /opt/PostgresPlus/9.5AS/bin/
Well, all answersabove are good but not in all cases.
Basically check the folder /etc/postgresql/
in most cases there will be one subfolder eg. /etc/postgresql/11/ (or /etc/postgresql/12) which means that you have installed 11 (or 12) version, however in many cases you may have many of such subfolders, so having them all means that all those versions had been ever installed and could be in use ... so be aware of this important trace.
ps using Ubuntu 18.04
I'm accessing an Ubuntu machine using PuTTY, and using gcc.
The default LANG environment variable on this machine is set to en_NZ.UTF-8, which causes GCC to think PuTTY is capable of displaying UTF-8 text, which it doesn't seem to be.
Maybe it's my font, I don't know - it does this:
foo.c:1: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â at end of input
If I set it with export LANG=en_NZ, then this causes GCC to behave correctly, I get:
foo.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' at end of input
but this then causes everything else to go wrong. For example
man foo
man: can't set the locale; make sure $LC_* and $LANG are correct
I've trawled Google and I can't for the life of me find out what I have to put in there for it to just use ASCII. en_NZ.ASCII doesn't work, nor do any of the other things I can find.
Thanks
LANG=en_NZ is correct. However, you must make locale files for en_NZ.
For Ubuntu, edit /var/lib/locales/supported.d/local and add en_NZ ISO-8859-1 to the file. If your system is another distribution (including Debian), the location will be different. Look at /usr/sbin/locale-gen and see where it stores this info.
Afterwards, run locale-gen to create the en_NZ locale file. Hope this helps!
Putty can display utf - I think it is in appearance -> translation (or something, I don't have access to it right now).
For Debian 5.0 Lenny:
aptitude install locales
If that's already installed:
dpkg-reconfigure locales