In an Windows environment:
\r (Carriage Return) moves the cursor to the beginning of the line without advancing to the next line.
\n (Line Feed) moves the cursor down to the next line without returning to the beginning of the line.
According to these definitions, \r\n and \n\r could be used interchangeably, am I right?
It should not matter whether you go down then left or left then down.
This question is similar, but it tells what everyone is used to, instead of explaining why.
Depends on the context.
If you're controlling an actual typewriter: Yes, they're the same.
If you're talking about file formats or network protocols: No, you have to use the right sequence of bytes (regardless of the reason those bytes were chosen originally).
Related
I'm trying to write a command that writes many lines of output, then rewinds to the beginning to overwrite them in sequence with more information. To do this, I count the number of lines, then move that many lines up with ANSI escape codes, then start outputting again. This works great if the many lines of output fit in the window I have open, but if there are too many lines, the cursor only ends up moving to the top visible line. How can I always go back to the beginning of the output, regardless of the window size?
One simpler option may be to use a library to do it instead of doing all the heavy lifting and calculations yourself have a look at something like BashSimpleCurses this would allow you to use the update function easily.
I am having a problem with Git Bash on Windows. It is always eating the last character on every line which wraps, leading me to sometimes having a repeated letter in my commit messages. Any ideas on how to solve this?
You can see this in the example below, the commit message is correct but not fully displayed.
Never mind, I figured out what the problem was. This only happens when the console overflows, which is why that initial letter g is there. Essentially the program doesn't know that initial g is there, but it still terminates the line after the same amount of characters, so the last letter is swallowed. However, it does not ignore your input, it just doesn't display it.
In similar question people recommend use File.read to read a whole file. But when I try to read png file (see fig. 1) I get only first line (see fig. 2). What am I doing wrong?
Use File.binread to read binary data.
On certain operating systems (notably Windows), there is a difference between opening a file in "binary mode" (8-bit characters) and "text mode" (7-bit characters). Because of this, these IO implementations can do things like detect end-of-file when there is a zero character, or mangle up characters outside of the ASCII range if you don't tell them to expect binary data.
If you open a file in Ruby, using mode "rb" instead of "r" will tell the OS that you expect binary data, and if it cares about that, it will do the right thing. File.binread() opens the underlying file it will read from with that mode.
i don't understand why sometimes the CUB sequence is allowed to continue through the previous line and sometimes not. the documentation tells it's not but in real situation...
http://vt100.net/docs/vt100-ug/chapter3.html#CUB
for exemple i have a screen filled with spaces on 80 columns and 24 lines.
i am at position line 3, column 4 which can be set with escape sequence : \033[3;4H
i move the cursor on the left 10 times with sequence \033[10D
wich will put me at position : line 2 column 76
so it worked ?!!
and sometimes it doesn't
please save me ! :)
I can reduce the situation but this is where i saw it :
I'm writing a vt* emulator and everithing works fine. i can launch emacs/vim and others but then i launched vttest in putty with the "script" command to record every typed characters and sequences. like so :
# script test
Script started, file is test
# vttest
...
when i do "cat test" in putty for exemple, it replays everythings like i did. when i play it with my emulator i am able to parse and to analyse every escape sequence they provide, but the display is not the same.
The wording on VT100.net is fairly clear:
If an attempt is made to move the cursor to the left of the left margin,
the cursor stops at the left margin.
In a recent discussion, someone pointed out that PuTTY honors a (non-VT100) capability bw, which quoting from ncurses' terminfo manual:
auto_left_margin bw bw cub1 wraps from col‐
umn 0 to last column
PuTTY's behavior for wrapping at the margins differs from VT100s, as you have seen. ncurses has a terminal entry named "putty", simply because PuTTY differs from all of the other terminals enough to make using a nuisance otherwise.
Why do line ending differ from platform to platform? Even why is there term like line ending in programming?
I prefer saving my codes in Unix/Linux format, even if I'm on Windows. Am I missing anything by not saving it in Windows or MacOS format? How does line ending effect in coding.
In the early days, when Typewriters were nearly the only way of getting output from a computer, CR and LF did different things. Unix started the tradition of using a single character to mark the end of a line, probably because it made their pipelining easier; their drivers could easily convert a single LF to CR/LF if need be. Linux is mostly a Unix clone so it keeps that convention. The others hold on to the CR/LF convention for historical reasons, even though it's not strictly necessary.
Some languages such as C, C++, and Python will let you specify the type of file when you open it, either binary or text. For text files a translation is performed so that a single LF is translated into the line ending convention required by the OS.
Basically everyone wanted to be different when creating OS's - Un*x's started with LF, then VMS and DOS wanted CR/LF (like a typewriter) and of course MAC wanted to be different so they went for CR only.
They just wanted to make it harder to transfer between OS's so that you 'bought' into one
Added because of comment
Up to the programmer - if you need to support different line endings then you must code for them. eg you could create a #define for the line ending and then have this change depending on compile options