Console isn't showing pretty characters in Shell - bash

I want to write some pretty, special characters taken from Web in my Shell Console with echo command. I want to write, for example, ▲ character, but it shows me ��� character. How can I solve the problem? Thanks!

I am using Ubuntu 64 bit also. You should check your terminal type and what kind of character-set does it supports. Take a look at this
and this

You need to make sure you character sets match and that you are using the correct terminal emulation. This can be set on both the Linux side or using your terminal client software.
e.g. ANSI, VT100, Linux
Character sets like UTF-8 does include symbols.

Related

Can’t display diacritic characters within Cygwin terminal

Both in Cygwin (minnty) and Git Bash I have set font to pl_PL/ISO-8859-2. It results (in both cases) in:
$ locale
LANG=pl_PL.ISO-8859-2
LC_CTYPE="pl_PL.ISO-8859-2"
LC_NUMERIC="pl_PL.ISO-8859-2"
LC_TIME="pl_PL.ISO-8859-2"
LC_COLLATE="pl_PL.ISO-8859-2"
LC_MONETARY="pl_PL.ISO-8859-2"
LC_MESSAGES="pl_PL.ISO-8859-2"
LC_ALL=
But in Cygwin, when I display Git commits’ comments - diacritical characters are not displayed properly (regardless of the font I use - e.g., Consolas, Lucida Console). The same commits’ comments are properly displayed in Git Bash. The comments have been UTF-8 encoded while saving.
I didn’t have this issue before, but once I reinstalled the OS now it occurs. Unfortunately I can’t tell what I have done differently.
Is it possible to fix that? I use Windows 7 32-bit.
In general, you're better off using UTF-8 and setting your locale to pl_PL.UTF-8. UTF-8 is capable of supporting all languages, including Polish. If that doesn't work, then there's a different issue which should be addressed independently. Git by default uses UTF-8 in most cases, and so does pretty much everything else on a Unix or Cygwin system.
If you really, absolutely insist upon using ISO-8859-2, then you'll need to set the i18n.logOutputEncoding to ISO-8859-2 so that it will render things in the proper character set. Note that if you have this set in one Git configuration (the Git Bash one) and not in the other (the Cygwin one), that will explain why you're seeing different behavior.
You may also want to set your system code page to UTF-8 by using chcp 65001 in a CMD window.

newlines when displayed in Windows

open OUT, ">output.txt";
print OUT "Hello\nWorld";
When I run the above perl code in a Unix system and then transfer output.txt to Windows and open it in Notepad it shows as:
HelloWorld
What do I need to do to get the newlines displaying properly in Windows?
Text file line endings are platform-specific. If you're creating a file intended for the Windows platform then you should use
open OUT, '>:crlf', 'output.txt' or die $!;
Then you can just
print OUT "Hello\nworld!\n";
as normal
The :crlf PerlIO layer is the default for Perl executables built for Windows, so you don't need to add it to code that will create files for its intended platform. For portable software you can check the host system by examining the built-in variable $^O
Windows uses carriage-return + linefeed:
print OUT "Hello\r\nWorld";
I wrote the File::Edit::Portable module that eliminates these problems. Although you can use it to write (along with many other things), you only need the read() functionality in this case.
Install the module, and at the top of your script, add:
use File::Edit::Portable;
When opening/reading the file, you can just do:
my $rw = File::Edit::Portable->new;
my $fh = $rw->read('file.txt');
No matter what the line endings are or what platform you're on, it does all of the cross-platform work in the background so you don't have to. That way, you can open the file on any system, regardless of what line endings you've decided to use, and it just works.
Newline handling is editor specific (there are a number of answers that claim it is OS specific, but that is, in real life, not true in general). However, it is true that on DOSish systems, longstanding convention is to use CRLF to indicate EOL (see also Why is fwrite writing more than I tell it to?)
If you try to open this file in any other editor than Notepad, you will notice that the text is properly displayed on two lines, with an indicator in a status bar or some other place that the file is opened in Unix mode or LF mode.
Unless you intend your file solely for viewing with Notepad, you don't have anything to worry about. Every other tool on Windows will deal fine with it.
However, Notepad does expect a CRLF sequence to mark the end of each line. If you do want to cater for it, then you can just output "\r\n" as #kizeloo suggests. I do prefer to use output layers when they are necessary.
Note that if you try to view such a file using an editor that requires a single LF to signify EOL, you may see ^Ms or other characters denoting the CR.

Debian console graphic error

when I try to install something over Putty, it looks like this:
so really buggy :).
Has anyone a suggestion for this?
It's probably something to do with UTF-8 handling on different terminal types.
You could try this solution I found on linux.debian.user:
What release of PuTTY are you using? I'm using PuTTY 0.63, which is
the latest release. In this version, the default value for the terminal
type string is xterm. At least it is for me. I have to explicitly change
it to putty, even after setting the remote character set to UTF-8. Make
sure the terminal type string is all lower case. Terminal type strings
are case sensitive. They have to match the terminal type definition in
ncurses. The putty terminal type definition in ncurses can be found in
/usr/share/terminfo/p. You can also try a terminal type string of
xterm-utf8. This terminal type definition in ncurses is found in
/usr/share/terminfo/x. The latest version of PuTTY can be downloaded
here:
http://www.chiark.greenend.org.uk/~sgtatham/putty
https://groups.google.com/forum/#!topic/linux.debian.user/Yy-kQu1RC44
It's indirectly related to UTF-8: the PuTTY developers chose to ignore VT100 line-drawing control sequences when UTF-8 encoding is used. Doing that requires any application that uses line-drawing to do some workaround.
You can work around this by one of these methods:
setting the NCURSES_NO_UTF8_ACS environment variable, as noted in the manual page, or
using a correct terminal description such as putty, which happens to have a special capability U8 defined, telling ncurses the same thing as the environment variable.

How to write newline in qt

I like to write linux newlines, under windows, but
QT automatically convert \n to \r\n based on the platform.
Any hints ?
Assuming you speak of QFile-s, you might pass an explicit OpenMode to open which has its QIODevice::Text bit cleared.

Numeric keys not working in Bash Terminal (MacBook Pro)

I'm trying to push a rails app to my remote Heroku repository from a MacBook Pro using the Bash Terminal.
The remote repository address contains numeric characters which are stripped out as soon as I copy/paste "git#heroku.com:app-name-[numbers].git". If I try to type the numbers in manually, the comp just beeps.
Really stuck on this one!
You've got a terminal setup problem. First thing to try is simply to close down the terminal and restart; that'll be a fresh session.
If that doesn't work, carefully type the following
stty sane^J
or
^Jreset^J
to set it to something normal.
It sounds as if you're getting characters echoed at least, so that may be easy. The ^J characters are LINEFEED, which is the actual ASCII character used for newline in UNIX-based systems.

Resources