This may be a dup of an older question, but I can't seem to narrow down my searching to get the answer I need from the flood of unrelated results.
I used to have export LC_ALL=C in my .bashrc, but I just recently figured out that Gnome terminal (or some libraries it uses?) doesn't support the "C" locale anymore. I hardly ever use the Gnome desktop, so it took me a long, long time to even notice the issue, and then still longer to figure out the cause.
Is there another locale setting with the same collate order as "C"? At least over the ASCII character (sub)set?
Related
Some characters that I enter in editor displayed not identical to those on keyboard. So I have error messages like this:
Character with decimal value 176 does not belong to the PL/I character
set. It will be ignored.
when trying to compile PL/I programm.
Sometimes character can displayed even properly, but I still have similar error message.
Examples of this characters are character that represents logical OR, logical NOT.
How to solve this problem? Is it a settings of editor, or settings of program IBM Personal Communications? Or may be it is better to enter 16-code of those symbols (how to do that if possible, and how to determine what code I need)?
There is a lot of places where this can go wrong...
The keyboard-driver on your client machine has to be configured correctly for the keyboard you use. But if other programs work correctly and only the mainframe emulation behaves strangely then this should be OK.
The PCOMM-session has to be configured to use the correct Host-codepage. Ask your mainframe technical guys what is used and configure your terminal emulation accordingly. Since we don't use PCOMM I can't help you with this, you will have to look around the session settings a bit.
In PL/I most characters are taken from the range that is identical in most EBCDIC codepages. The main exceptions are the characters for the OR- and NOT-operators which may differ. IBM-default for OR is '4F'X, which is a pipe-character '|' in codepage 1140 (English), but an exclamation mark '!' in codepage 1141 (German). Default for NOT is '5F'X which is a logical NOT-sign '¬' in 1140 but a caret '^' in 1141.
Since these problems are well known the compiler offers two options OR() and NOT() to set the characters to be used for these operators. So you might look in your compile-listing whether these parameters are set in your installation and what their values are since these are the characters you have to use.
I am turning to use Sublime3 instead of Notepad++. I have some concern when working with Perl/PHP or any kind of languages that use dollar sign for declare variable.
Here is an example, in Notepad ++:
As can be seen, "HELO $name" was displayed with different colors.
By that way, we can easily recognize there is a variable in the string.
In Sublime 3 , it looked like this:
So you can see there are no different between text and variable. It would caused confusion in some case.
May I know is there are any solution for this ?
Thank you and best regards.
Alex
This is self-promoting, but it will actually solve the problem
You may want to check out my Neon Color Scheme, available via Package Control. Its goal is to make as many languages as possible look as good as possible, and has hundreds of selectors that are specific for many different syntaxes, including Perl and PHP. Specifically, both languages support highlighting for string interpolation. Here is your code using Sublime's Perl syntax from dev build 3118, which should be very similar to the latest public build, which you should be using if you're not registered yet:
And here is the equivalent code in PHP:
Please note that these images were taken using a work-in-progress version of Neon, which I'm planning on releasing in the next day or so. The current version should look the same, as I don't think I've edited any of these scopes, but if not just let me know and I'll point you to the dev version.
when I sshed into another machine in xterm, the character I deleted by either backspacce or ctrl+k, remains on the screen. but physically they have been deleted, as when you exectue the script, the machine responds in a way that the delete has conducted. The only way to display properly is to let the cursor moving through the deleted words, either by space or typing other characters.
Same thing applies when you using vim. specifically after page down, the screen displays a overlap between the previous page and current page.
The screen displays properly without ssh.
I am using gentoo with the following compile flag (if it is related).
[ebuild R ] x11-terms/xterm-314 USE="openpty truetype unicode -Xaw3d -toolbar" 0 KiB
Sounds like a locale problem. Some Linux's by the way honor an stty -iutf8 setting, and others may not. Either that, or a difference in locale settings on the local and remote machines is the first place to check.
Thomas's answer led me to a solution for this very same problem. My LANG environment variable was incorrectly set on my local machine. For my case,setting LANG=en_US.UTF-8
fixed the problem.
This is a very specific issue but, based on what I've seen online, a surprisingly common one. I'm on a rather old version of Scientific Linux 5, which is based on Red Hat. I use vim with the Solarized vim color scheme, and my TERM environment variable is usually set to xterm-256color. This worked fine until I started using tmux. On non-empty lines in vim, the color scheme only extended to the end of the document's characters, the remaining whitespace being plain back background.
The stock fix for this in online guides is to set TERM='screen-256color'. However, upon doing this I would get the ominous warning: WARNING: terminal is not fully functional - (press RETURN), when trying to do innocuous things like read man pages. However, everything seemed to be working fine, and the Solarized bug was fixed.
I've found a functional fix - using TERM='xterm-256color' by default and adding this line to my .bashrc:
alias v='function _vim(){ TERM='screen-256color'; vim $1; TERM='xterm-256color'; };_vim'
but it seems like a hack. Anecdotally, I've also set alias tmux='tmux -2', which is a common suggestion with color-scheme-related issues.
I also know that the terminfo screen-256color is available on my machine.
So, really, the main befuddling thing is that, when using TERM='screen-256color', I'm getting those warnings about full functionality when nothing seems to be wrong.
I don't have root access, so ideally any fix suggestions wouldn't need that.
EDIT: I should mention that TERM='screen-256color-bce' gave the same problems as TERM='screen-256color'.
The user's environment is not specified, but likely using bash and less (Scientific Linux 5 does not have more).
The package list on Scientific Linux 5's ftp site, shows ncurses-5.5-24.20060715.src.rpm, which does not include screen-256color (it was added to ncurses in October 2006). That system might have the later terminal database by some post-install change.
An application using termcap would not see this terminal description. Scientific Linux's bash and less programs could have used termcap rather than terminfo. A quick check of the changelog for bash-3.2-21.el5 says
* Fri Feb 1 2008 Miroslav Lichvar <mlichvar#redhat.com> - 3.2-21
- Link with libtermcap
On some systems, a missing termcap entry will cause a warning. But with Scientific Linux 5, the given warning message comes from less, which checks its terminal description (using the termcap interface), to ensure that it can clear the remainder of the current line, the remainder of the screen and the entire screen.
In Scientific Linux 5, the less package is built with ncurses. A problem with less using TERM=screen-256color would be one of these possibilities
the screen-256color entry is not really installed, or
there is some problem with the termcap interface provided by ncurses.
While there were ongoing performance-fixes for the screen program around this time, the former seems the more likely, as seen in this discussion of a poorly-written entry for screen-256color in early 2006: Re: screen-256color terminfo entry?. What I get from reading this is that there was some poorly-written terminal description (not part of ncurses) which produced the problem. By the time it was proposed for inclusion in ncurses (October 2006), the problem had been repaired. In any case, it would have been corrected at that point.
Warning: you know how they say "there's not such thing as a stupid question"? Well, this one is, or, I suspect it's really minor, but wth, why not ask. Search engines didn't bring me anything remotely useful, though that could be bad searchterm-fu.
I recently downloaded sqlite3 onto Ubuntu 10 to start learning SQL commands. I un-tar'd 3.7.12.01 and make installed.
After creating a test.db with create table test (id) I decided to see what I'd get if I cat it. Just because.
The result is an EOT character (u+0004) which is sitting right over my prompt. Illustrated screenshot: http://imgur.com/omfMa
I realise this is not the type of file you would use cat on. I only want to know, before I go further,
does the strange placement of this character signal any future issues when actually playing around with SQL, or some issue with newlines, or fonts (this is monofur set at a high font size) or similar?
I've never seen a result character placed directly over my prompt before.
The character is placed over your prompt, because it is a double-width character, and terminals in general are not good at handling double-width characters. It does not mean anything.
There are some control codes which can do very funny things with your terminal, such as changing colors, fonts etc.
But none of them do really harm - you should be able to reset your terminal to a healthy state, or close it and open a new one.