Can you please help me regarding
How to select below query in Oracle.
I am trying to spool a special character from SQL*plus. But it is showing like ????
select '§' from dual;
Unless your database character set is defined to US7ASCII this should be no problem.
You local character set has to match setting of NLS_LANG.
Example:
$ locale charmap
UTF-8
$ echo $LANG
en_US.UTF-8
Then NLS_LANG environment variable should be set to
NLS_LANG={your_language}_{your_country}.AL32UTF8
Then SQL*Plus should work fine.
Related
I'm trying to add an environment variable to my system via
sudo nano /etc/environment
The value is a long string containing a hash, #.
With the # included, the string is not stored fully; characters after the # are gone.
Without the # included, the string is stored fully.
I have tried to wrap the string in " ":
MY_VARIABLE="34534554345 # DFGDGDFG"
I expect the variable to be stored fully, like this:
34534554345#DFGDGDFG
Not this:
34534554345
PAM interprets /etc/environment, not a shell. It's intended to be simple KEY=VALUE on each line with no need for quotes. # marks a comment and there is no way to escape it.
You can use /etc/profile to define your environment variable. It should make it available system wide in most cases.
/etc/environment
TEST2="12345#6789"
/etc/profile
export TEST="12345 #6789"
Result:
root#tempmon:~ $ env|grep TEST
TEST=12345# 6789
TEST2=12345
I am using Gina Trapiani's excellent todo.sh to organize my todo-list.
However being a dane, it would be nice if the script accepted special danish characters like ø and æ.
I am an absolute UNIX-n00b, so it would be a great help if anybody could tell me how to fix this! :)
Slowly, the Unix world is moving from ASCII and other regional encodings to UTF-8. You need to be running a UTF terminal, such as a modern xterm or putty.
In your ~/.bash_profile set you language to be one of the UTF-8 variants.
export LANG=C.UTF-8
or
export LANG=en_AU.UTF-8
etc..
You should then be able to write UTF-8 characters in the terminal, and include them in bash scripts.
#!/bin/bash
echo "UTF-8 is græat ☺"
See also: https://serverfault.com/questions/11015/utf-8-and-shell-scripts
What does this command show?
locale
It should show something like this for you:
LC_CTYPE="da_DK.UTF-8"
LC_NUMERIC="da_DK.UTF-8"
LC_TIME="da_DK.UTF-8"
LC_COLLATE="da_DK.UTF-8"
LC_MONETARY="da_DK.UTF-8"
LC_MESSAGES="da_DK.UTF-8"
LC_PAPER="da_DK.UTF-8"
LC_NAME="da_DK.UTF-8"
LC_ADDRESS="da_DK.UTF-8"
LC_TELEPHONE="da_DK.UTF-8"
LC_MEASUREMENT="da_DK.UTF-8"
LC_IDENTIFICATION="da_DK.UTF-8"
LC_ALL=
If not, you might try doing this before you run your script:
LANG=da_DK.UTF-8
You don't say what happens when you run the script and it encounters these characters. Are they in the todo file? Are they entered at a prompt? Is there an error message? Is something output in place of the expected output?
Try this and see what you get:
read -p "Enter some characters" string
echo "$string"
I can't find a way to display bash special chars. For example the hostname is \h.
If I do :
echo '\h \\h'
it won't work ( display h \h). How can I make it display my hostname ?
ref : http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/bash-prompt-escape-sequences.html
Those are only evaluated in the PS1 and PS2 variables. You can test them dynamically like this:
PS1="\h"
The bash will then display the new prompt. Just open a new bash if you mess it up, it will not be saved.
The HOWTO told you it is "Prompt Escape Sequences", only works when you put then in PS1 or PS2,
My ˋgitˋ is in german, it says:
ˋAuf Zweig masterˋ
instead of
On branch master
with git status.
What's the reason for this?
Probably you locale is german. You can see it by locale. Try to change it by: export LANG="en_US.UTF-8"
The reason for this is that your command line language is set to German.
So when you do:
echo $LANG
you will see:
de_DE.UTF-8
To change this, do:
echo "export LANG=en_US.UTF-8" >> ~/.bashrc
assuming your standard shell is bash.
Don't forget:
source ~/.bashrc
Sometimes changing the LANG environment variable alone is not good enough.
You may also need to add LC_ALL
export LC_ALL=en_US.UTF-8
According to The IEEE and The Open Group - Environment Variables.
It is because the environment variables starting by LC_* will be used first by your system before LANG:
The values of locale categories shall be determined by a precedence
order; the first condition met below determines the value:
If the LC_ALL environment variable is defined and is not null, the
value of LC_ALL shall be used.
If the LC_* environment variable (LC_COLLATE, LC_CTYPE, LC_MESSAGES,
LC_MONETARY, LC_NUMERIC, LC_TIME) is defined and is not null, the
value of the environment variable shall be used to initialize the
category that corresponds to the environment variable.
If the LANG environment variable is defined and is not null, the
value of the LANG environment variable shall be used.
If the LANG environment variable is not set or is set to the empty
string, the implementation-defined default locale shall be used.
To change it permanently, you need to paste the code above into your favourite shell configuration file (probably ~/.bashrc or ~/.zshrc)
Then to apply the modification do:
$ source ~/.bashrc
or
$ source ~/.zshrc
Otherwise, just open a new terminal.
In my case, setting LANG or LC_ALL was not enough. I also had a LANGUAGE environment variable which was set to en_GB:en_US:de. Despite the ordering, which is presumably an order of preference, it resulted in a German language response from git and other commandline-programmes. When I changed it to en_GB:en_US, git and other programmes became English.
As explain in #Tom comment, it is possible to add alias. In my case, I add in my Ubuntu ~/.bash_aliases
alias giten='LANGUAGE=en_GB:en_Us git'
so if I use git, it is in my language, if I use giten, it is in english
NOTA: by this way, the auto-completion is lost
Now I change my gnome-terminal's character encoding to "GBK" (default it is UTF-8), but how can I get the value(character encoding) in my Linux?
The terminal uses environment variables to determine which character set to use, therefore you can determine it by looking at those variables:
echo $LC_CTYPE
or
echo $LANG
locale command with no arguments will print the values of all of the relevant environment variables except for LANGUAGE.
For current encoding:
locale charmap
For available locales:
locale -a
For available encodings:
locale -m
Check encoding and language:
$ echo $LC_CTYPE
ISO-8859-1
$ echo $LANG
pt_BR
Get all languages:
$ locale -a
Change to pt_PT.utf8:
$ export LC_ALL=pt_PT.utf8
$ export LANG="$LC_ALL"
If you have Python:
python -c "import sys; print(sys.stdout.encoding)"
To my knowledge, no.
Circumstantial indications from $LC_CTYPE, locale and such might seem alluring, but these are completely separated from the encoding the terminal application (actually an emulator) happens to be using when displaying characters on the screen.
They only way to detect encoding for sure is to output something only present in the encoding, e.g. ä, take a screenshot, analyze that image and check if the output character is correct.
So no, it's not possible, sadly.
To see the current locale information use locale command. Below is an example on RHEL 7.8
[usr#host ~]$ locale
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=
Examination of https://invisible-island.net/xterm/ctlseqs/ctlseqs.html, the xterm control character documentation, shows that it follows the ISO 2022 standard for character set switching. In particular ESC % G selects UTF-8.
So to force the terminal to use UTF-8, this command would need to be sent. I find no way of querying which character set is currently in use, but there are ways of discovering if the terminal supports national replacement character sets.
However, from charsets(7), it doesn't look like GBK (or GB2312) is an encoding supported by ISO 2022 and xterm doesn't support it natively. So your best bet might be to use iconv to convert to UTF-8.
Further reading shows that a (significant) subset of GBK is EUC, which is a ISO2022 code, so ISO2022 capable terminals may be able to display GBK natively after all, but I can't find any mention of activating this programmatically, so the terminal's user interface would be the only recourse.