I wrote more than 7 programs that is expected to print more than 296 lines in the command line. But my windows pc (32bit with Code::Blocks IDE) only prints 296 lines each time. One of the code was:
for (int x=0; x < 300; ++x)
cout << x << "\n";
First number the program above printed was 4 (I don't know what it does with 0,1,2 and 3) and last number was 299 in 296th line. I guess something is limited there. But what, ostream in c++, my IDE or the command prompt itself?
Since the method you used to check what number were output was by scrolling back in the command window, you're not seeing the first part of your output.
The scrollback window has a limit to the number of lines it keeps around. After you run your program and scroll back to see the number 4, press enter 4 times and scroll back again. The number will now be 8. This doesn't mean your program didn't print the numbers 0 through 7.
If you right-click on the command prompt window's title bar and select Properties, go to the Layout tab. There is a place to specify the scrollback buffer size. It appears the default is 300, since I've never changed this setting.
Related
I just installed Win 10 1809 on my Dell PC, and it seems to run okay. But the first thing I did was start up VS Code. I wanted to run yarn start for my React project, but I had to type it way down in the terminal window, while the prompt was at the top. It worked though.
And when I open any project file, there seems to be approximately 100 blank lines appended at the end of each. But the line numbers don't go down that far and the cursor stops at the last line number. But the scroll bar acts as if those blank lines are there.
So I'm guessing the same number of blank lines are being added to the terminal too. But in the terminal window, the cursor is positioned at the bottom of the scrollable window.
What's going on? Is there a fix?
EDITED:
I see that I can scroll the file's window up until the cursor and last line is at the top, but no further, regardless of the window size. Maybe this has always be the case, and I never noticed. But now because of my terminal problem, I am suspicious of everything and checking for any abnormalities. So I don't think that extra blank lines are being added to my files. Sorry for the mistake.
But the terminal problem persists. The screen clip below shows the terminal display after I enter "yarn start". The typed input shows up way down from the initial prompt, and the blank area is a long string of "0D0A" characters. Sometimes I can click on "kill Terminal" and then start a new one and the new one works correctly. But not always.
Still trying to figure this out.
Can you share snapshots for your problems?
This is some hint for your problem
In VS Code, type
Linux / Windows: Ctrl + Shift + P
MacOS: Cmd + Shift + P
Type Settings to go Settings
At settings, search end of file, at here you can configure something for your problem with auto append blank lines each file
I hope it will help you :)
Your Terminal Problem is described as Bug in VS Code Issues.
As of July 2019 the intergration is pending due to stability problems.
https://github.com/Microsoft/vscode/issues/57803
Addendum (August 2019):
The Problem seams to be fixed with VS Code 1.37.1 and Windows 10 Patchlevel 1903
Did you try uninstalling and reinstalling?
Going back to your questions.
What's going on? No idea.
Fix. Use this extension https://marketplace.visualstudio.com/items?itemName=rintoj.blank-line-organizer
or
Open Visual Studio project and collapse all the folder and make it handy.
Now press “ Control + Shift + H “ key combination and you can see the Popup which shows Find and Replace options.
In the Find place input “^&\n” combination and select Use Regular Expression checkbox without fail as this input will mainly work with the regular expressions only.
In the replace field leave it empty so nothing will be replaced rather remove the empty blank lines.
In the input Find field we have give ^ for Start of the line and $ for end of line and \n which is for new line break.
source for second solution: http://www.f5debug.net/post/2015/01/03/How-to-remove-Blank-lines-between-codes-in-Visual-Studio-Code-editor.aspx
The extension will be useful overall especially when working in a team project where a lot of people might be leaving too many empty lines. Good luck
I am on Ubuntu and use Gvim. Based on my understanding,I have set tab to expand to 4 spaces. I did not even touch the line that has create_namespace but git diff shows it as shifted by a character. It seems perfectly fine in the editor or when I run cat. Same issue is when I added a new line of txt cluster_token and it shows as shifted by a character in git diff. I have wasted hours trying to understand this silly issue but no clue. What is the issue and how do I fix it?
- echo "--create_namespace"
+ echo "--create_namespace" //Did not even touch this line
echo "--all"
echo "--custom_merge_pipeline_commands"
+ echo "--cluster_token" //Looks fine in editor
If this is TL;DR, skip down to the bolded text below.
As I noted in a comment, the issue of spaces vs tabs sets off flame wars, so I'm going to attempt to be completely neutral on the subject. (Note: I did say attempt. :-) ) It's also worth covering a bit of history, i.e., how we got here in the first place. Also, there is an entirely separate, though currently beta, StackExchange web site devoted to vi / vim at https://vi.stackexchange.com/ so I am not going to get into the many vim settings available here.
First, note that tabs go back to the days of mechanical typewriters (well, probably even before then).
Different models had different features, but most had a key labeled TAB that, when pressed, caused the platen—the rubber roller that holds the paper—to slide leftward (assuming a Western-style, left-to-right carriage typewriter) from its current position to the next tab stop. Tab stops were set mechanically, since all of this was run by wires and springs. Since the type bars would always strike the paper at the center where the ribbon was held against the paper, sliding the platen leftward has the effect of making the next character come out somewhere to the right. How far to the right, depends on the current column and, of course, the tab stop settings.
Early computer interfaces used or emulated mechanical typewriters—well, more precisely, teletype interrfaces—sometimes complete with the exact same mechanically-controlled tab stops. When glass ttys came out, they tended to emulate the existing TTYs. Over time, the terminals got smarter, to the point where some had software-adjustable tab stops.
Others, however, limited tab stops in software to simply "every N columns", where N was variable. DEC chose 10 for some of their early systems, but 8 proved more popular and became the default. Here, sending an ASCII TAB (code 9 decimal) byte to the display terminal caused the terminal to move the cursor from whichever column it was in now, to one up-to-but-not-exceeding N (usually 8) characters to the right. (The behavior of a cursor close to the end of the physical screen line varied, and still varies in software emulations, but the VT100 behavior is pretty common now.)
We no longer use any of these bits of hardware—at least, not commonly—but we do emulate them. Pressing the TAB key in an editor tends to move the cursor to "the next tab stop", wherever that may be. Terminal emulators will emulate whatever terminal—often, again, the VT100, which has variable tab stops (set via escape sequences) but defaults to every eighth column (columns 9, 17, 25, and so on, if we number the first column 1—as is traditional—instead of the proper mathematical column zero :-) ).
For storing text in files, however, there is an option: we can store the literal ASCII TAB character (or the Unicode equivalent which is U+0009), or we can store however many spaces it might take to get to the selected column. If we store a literal TAB, it is up to whatever it is that displays the file to choose which column is the desired column. If we store literal space characters, whatever is displaying the file must display that many space characters.1 The effect is that if we store literal TABs, the display depends on previous output (since the cursor column depends on previous output), but if we store literal spaces, it does not.
Meanwhile, when git diff displays lines, it inserts one character in front of each line. If the line being displayed starts with a literal TAB followed by the word old, what happens is that git diff writes a space or plus or minus character, then a TAB, then the next character. Assuming your terminal has its tab-stops at columns 9, 17, 25, and so on, the character after the TAB shows up in column 9:
0 1
1234567890123456789
- old
If, on the other hand, the line in the file starts with eight spaces followed by the word new, what you see is the git diff character, then eight spaces, then the word in column 10:
0 1
1234567890123456789
+ new
Stacking these atop one another we get:
0 1
1234567890123456789
- old
+ new
which is what you are seeing. This means that your claim:
- echo "--create_namespace"
+ echo "--create_namespace" //Did not even touch this line
is at best half-true: you might not have touched the line, but your editor did. It replaced at least one literal TAB character with spaces. (We cannot tell from here how many such characters were changed—perhaps, for instance, it replaced one TAB with four spaces, leaving four existing spaces in place, if you have everything rigged up to use columns 5, 9, 13, 17, and so on.)
1It is now time to avoid an entire separate aside on fixed vs variable pitch fonts. :-)
I have been playing around with the ansi colours in OSX terminal (bash v.3.2.57, Yosmite).
I have a problem with background colour behaviour once I fill up a terminal-window (as in, when it scrolls down).
The background colour will fill the right hand side white space, whilst also "skipping" a line (see picture). It works as I want it to until the output makes the window scroll. If I use the "clear" command the output will look fine until the output fills up a terminal window again.
The code below was simply getting the different combinations of colours (I truncated it a bit for this problem).
I have a feeling terminal is to blame rather than python, because the output works initially. Can anyone explain this behaviour? Cheers.
#coloured text in terminal
#ANSI escape sequences
std_txt = '\033[0m'
print('colour test' +'\n')
print(' X in 033[0;Xm')
for x in range(30,35):
print ''.join(["\033[0;",str(x), 'm']) + 'test' +'\t' + str(x)
print std_txt +'\n' + ('end')
print('colour test 2' +'\n')
print(' X in 033[0;30;Xm')
for x in range(40,45):
print ''.join(["\033[0;30;",str(x), 'm']) + 'test' +'\t' + str(x)
print std_txt +'\n' + ('end')
ps: What I mean by filling up a terminal window or scrolling.
If your terminal-window is 80x24, filling it up will be using 24 lines, and >25 would make it scroll. Sorry, I found it hard to explain this in the problem.
The problem is that you're not resetting the color before the newline, so the terminal tries to be helpful.
Change
print ''.join(["\033[0;30;",str(x), 'm']) + 'test' +'\t' + str(x)
To:
print ''.join(["\033[0;30;",str(x), 'm']) + 'test' +'\t' + str(x) + std_txt
I am parsing a csv file and the file has "\t" characters after every column. Why is it that when I print out the individual lines in terminal or open the file in my text editor that the tab spacing between each of the columns is different?
When you use tab, you're essentially moving to the next tab location, not moving over a specific distance. To see the difference, try using 4 spaces instead of tab. Or, alternatively, run the following code, and I think it may become clear to you.
puts "Hel\tlo world!"
puts "H\tello world!"
puts "Hell\to world!"
Hope that helps.
Do you mean something like
1 1
12345678 1
as a result of
puts "1\t1"
puts "12345678\t1"
A tab jumps to the next position in 8-space steps (8 spaces is a common distance, but it depends on settings of your editor. For ruby often is 2-space distance is used).
If the previous text is longer then 8 characters, then you jump to the next position and you have the impression of different tab spacing.
When I run my program in VS2010,
because my output quite a lot,the console just discards my previous output.
For example, consider my output to be of 400 lines, lines 1 to 80 are not displayed, only lines 81 to 400 are displayed.
Any idea of how I can see the entire output?
You can change the buffering settings of the console: right click the title bar of the console window and select "Properties." On the "Layout" tab, change the "Height" of the Screen Buffer to some large number (9999, for example).
Run your program again.
Of course, if you have a large amount of output that you need to inspect on a regular basis, it's probably best to write to a file instead.
Console.BufferHeight = x;
Console.BufferWidth = x;
Sets the height and width of the console buffer.
Right before your output.
You can set it dynamically based on output but be sure to remember that if a line is longer than the width you will have additional lines to contend with.