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.
Related
The Windows Ruby and irb was giving no output, partial lines of output or complaining about encountering \r in the middle of a line. After some experimentation I figured out what was happening and thought it might help someone else to post and answer even though it was pretty basic.
Ruby doesn't work well with the Windows end of line character even though you installed the Windows version. You should make the EOL character the *NIX one. If you happen to use Notepad++, just open the file, and choose Edit -> EOL Conversion -> UNIX(LF) and it will fix all the EOL characters and any new EOL characters will be correct. Whichever selection there is grayed out, is the one you already have.
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.
We try to convert the source files of a TCL/TK application to UTF-8, because this is the default charset of the plattforms we use for development (Linux and OSX).
Our problem is now that windows uses "cp1252" as system encoding, and because of this displays labels and buttons with (for example) german umlauts wrong.
The only solution we found yet would be to add "-encoding UTF-8" to all "wish" calls and "source" commands.
(There is also "encoding system UTF-8", but the documentation says that you shouldn't use it because of problems with system calls)
Is there a way to tell TCL that it should use UTF-8 as default encoding for all source files, or maybe another solution for this problem?
The solution suggested in the TCL chat:
Create and use your own versions of "open" und "source" (like "my_open" and "my_source") which then call the original commands with "-encoding utf-8"
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.
I wrote a small download script in the C++ part of my QtQuick2 app. This works just perfectly fine when I'm building the app for Mac OS 10.9.
For testing I download this file and when it's done I verify it against the given md5 check sum b3215c06647bc550406a9c8ccc378756
Only when I build the app on a windows PC the verification fails. On the second look I recognise that the size of the downloaded file differ with each downlaod, while the "size on disk" stays every time the same.
Do you have any idea what might trigger the strange behaviour in windows os?
Thanks in advance.
If it helps to solve the problem, I will show you my download script, but it's a pretty simple "read-all-write-to-file" script which runs every two seconds.
Could binary/text writing mode affects the result?
UPD: If you use QFile with QIODevice::Text it may behave differently depending on platform.
When reading, the end-of-line terminators are translated to '\n'. When writing, the end-of-line terminators are translated to the local encoding, for example '\r\n' for Win32.