In VS code (using C++) trying to printf or cout any value will display output upto the last newline character and ignore output after it (if there is any).
Code example
Output after the green underlined \n is not displayed in debug console which shows output before the newline character only.
Output
Removing the newline character or adding one at the end of last output value will show the full output.
Using CMD or running the generated exe gives the full output regardless of the newline character.
Related
I an running a bash/.dat script (Mac terminal) and part of it is converting each line return into a TAB (to get it ready for nicely importing into Excel). The problem is that I also want to remove all extra blank lines except a single blank line when comes between two filled lines. So...
Line pre-A is blank
Line A has text
Line B has text
Line C is blank
Line D has text
Line E is blank
Line F is blank
Line C above would become a TAB and Line E and F (and pre-A) would be deleted. Also, sometimes there is a blank line before Line A (labelled Line pre-A above), so I'd want it removed but not replaced with a TAB.
So the result would be:
Line A text [TAB] Line B text [TAB] [TAB] Line D text
...and it'd be OK if Line D text was followed by a [TAB]. Make sense? Is this doable and, if so, how?
Thanks!
If perl is your option, would you please try:
perl -0777pe 's/^\n+//; s/\n{3,}/\t/g; s/\n/\t/g' file.txt
The -0777 option tells perl to slurp all lines at once to process
newline characters between lines.
The -pe option enables the one-liner programming.
The first substitution s/^\n+// removes the pre blank line(s).
The next s/\n{3,}/\t/g converts three or more consecutive newline
characters (meaning two or more blank lines) into a tab character.
The last s/\n/\t/g converts the newline characters into the same number
of tab characters.
I'm working on a small text file with a list of words in it that I want to add a new word to, and then sort. The file doesn't have a newline at the end when I start, but does after the sort. Why? Can I avoid this behavior or is there a way to strip the newline back out?
Example:
words.txt looks like
apple
cookie
salmon
I then run printf "\norange" >> words.txt; sort words.txt -o words.txt
I use printf rather than echo figuring that'll avoid the newline, but the file then reads
apple
cookie
orange
salmon
#newline here
If I just run printf "\norange" >> words.txt orange appears at the bottom of the file, with no newline, ie;
apple
cookie
salmon
orange
This behavior is explicitly defined in the POSIX specification for sort:
The input files shall be text files, except that the sort utility shall add a newline to the end of a file ending with an incomplete last line.
As a UNIX "text file" is only valid if all lines end in newlines, as also defined in the POSIX standard:
Text file - A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the newline character. Although POSIX.1-2008 does not distinguish between text files and binary files (see the ISO C standard), many utilities only produce predictable or meaningful output when operating on text files. The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections.
Think about what you are asking sort to do.
You are asking it "take all the lines, and sort them in order."
You've given it a file containing four lines, which it splits to the following strings:
"salmon\n"
"cookie\n"
"orange"
It sorts these for you dutifully:
"cookie\n"
"orange"
"salmon\n"
And it then outputs them as a single string:
"cookie
orangesalmon
"
That is almost certainly exactly what you do not want.
So instead, if your file is missing the terminating newline that it should have had, the sort program understands that, most likely, you still intended that last line to be a line, rather than just a fragment of a line. It appends a \n to the string "orange", making it "orange\n". Then it can be sorted properly, without "orange" getting concatenated with whatever line happens to come immediately after it:
"cookie\n"
"orange\n"
"salmon\n"
So when it then outputs them as a single string, it looks a lot better:
"cookie
orange
salmon
"
You could strip the last character off the file, the one from the end of "salmon\n", using a range of handy tools such as awk, sed, perl, php, or even raw bash. This is covered elsewhere, in places like:
How can I remove the last character of a file in unix?
But please don't do that. You'll just cause problems for all other utilities that have to handle your files, like sort. And if you assume that there is no terminating newline in your files, then you will make your code brittle: any part of the toolchain which "fixes" your error (as sort kinda does here) will "break" your code.
Instead, treat text files the way they are meant to be treated in unix: a sequence of "lines" (strings of zero or more non-newline bytes), each followed by a newline.
So newlines are line-terminators, not line-separators.
There is a coding style where prints and echos are done with the newline leading. This is wrong for many reasons, including creating malformed text files, and causing the output of the program to be concatenated with the command prompt. printf "orange\n" is correct style, and also more readable: at a glance someone maintaining your code can tell you're printing the word "orange" and a newline, whereas printf "\norange" looks at first glance like it's printing a backslash and the phrase "no range" with a missing space.
If I evaluate something in Immediate that produces a long and complex string, the debugger encodes everything in C string escapes, so I end up with a mess of \n, \t, and so on throughout my text which I then have to fix by hand. (Which is particularly annoying in the case of \n, as most text editors can't do multiline search-and-replace!)
Is there any way to get the debugger to give me the raw, un-munged, multi-line string value?
We could check the string value with Text Visualizer in Watch window, which will show the string value without any \n and \t content.
Please add a breakpoint in the string variable in your code and start debugging your code. When the breakpoint hit, you could right-click the variable and choose "Add Watch" Then press F11 to go to next line of code. Now you could view the string value from Watch window by click the "Text Visualizer" icon. It will not show the \n and \t.
You can use C# Interactive Window (Views > Other Windows > C# Interactive).
Usage:
Type command:
Console.Write("r1bqkb1r/pp3ppp/2p5/3pP3/P2Q1P2/2N1B3/1PP3PP/R4RK1 w - - 1 2\nr1bqkb1r/pp3ppp/2p5/3pP3/P2Q1P2/2N1B3/1PP3PP/R4RK1 w - - 1 2")
Then I'll get:
r1bqkb1r/pp3ppp/2p5/3pP3/P2Q1P2/2N1B3/1PP3PP/R4RK1 w - - 1 2
r1bqkb1r/pp3ppp/2p5/3pP3/P2Q1P2/2N1B3/1PP3PP/R4RK1 w - - 1 2
C# Interactive Window is independent from the project so it will work on all projects of all language (C#, C++,...)
Here is the demo image:
Set a format specifier at the end of the expression in the immediate window.
Problem:
? "test string with escape chars \r\nThis is on the next line"
"test string with escape chars \r\nThis is on the next line"
Add the , nq format specifier to the end:
? "test string with escape chars \r\nThis is on the next line", nq
test string with escape chars
This is on the next line
This works exactly the same with a real variable:
? testvariable, nq
test string with escape chars
This is on the next line
(I tried the answer from Konstantine Kozachuck using a format specifier on the Print statement and it did not work the same way the ? statement did, but it did help me figure out want I wanted.)
Print variableName,sb.
Example (Immediate window):
>"raw\nmultiline\tstring",sb
raw
multiline string
Documentation: https://learn.microsoft.com/en-us/visualstudio/debugger/format-specifiers-in-cpp?view=vs-2019
I'm rewriting a GoldParser Grammar for VBScript. In VBScript Statements are terminated using either a newline or ':'. Therefore i use the following terminal:
NewLine = {All Newline}
| ':'
Because every statement has to end with the Newline terminal, only programs ending with an empty line are accepted. How can i extend the newline terminal to also accept programs not ending with an empty line? I tried the following:
NewLine = {All Newline}
| ':'
| {EOF}
This does not work because the {EOF} (End of File) group does not exist.
EOF is a special token and I'm not aware of any syntax allowing you to use it in a production rule. It is emitted when the tokenizer receives no more data, and as such it is not a control character you could use in a terminal definition either.
That being said, you have different possibilities to parse the (strictly speaking invalid) input. The simplest may be to just append a newline at the end of the string or text being tokenized. While this will not make it parse correctly in the GOLD Builder test window, it will make your code process the data as expected and it will not add complexity to the grammar.
So I have a strange question. I have written a script that re-formats data files. I basically create new files with the right column order, spacing, and such. I then unix2dos these files (the program I am formatting these files for is DIPS for windows, and I assume that the files should be ansi). When I go to open the files in the DIPS Program however an error occurs and the file won't open.
When I create the same kind of data file through the DIPS program and open it in note pad, it matches exactly with the data files I have created with my script.
On the other hand if I open the data files that I have created with my script in Kedit first, save them, and then open them in the DIPS program everything works.
My question is what could saving in Kedit possibly do that unix2dos does not?
(Also if I try using note pad or word pad to save instead of Kedit the file doesn't open in DIPS)
Here is what was created using the diff command in unix
"
1,16c1,16
* This file is generated by Dips for Windows.
* The following 2 lines are the Title of this file.
Cobre Panama
Drill Hole B11106-GT
Number of Traverses: 0
Global Orientation is:
DIP/DIPDIRECTION
0.000000 (Declination)
NO QUANTITY
Number of extra columns are: 0
--
* This file is generated by Dips for Windows.
* The following 2 lines are the Title of this file.
Cobre Panama
Drill Hole B11106-GT
Number of Traverses: 0
Global Orientation is:
DIP/DIPDIRECTION
0.000000 (Declination)
NO QUANTITY
Number of extra columns are: 0
18c18
--
440c440
--
442c442
-1
-1
"
Any help would be appreciated! Thanks!
Okay! Figured it out.
Simply when you unix2dos your file you do not strip any space characters in between the last letter in a line and the line break character. When saving in Kedit you do strip the spaces between the last letter in a line and the line break character.
In my script I had a poor programing practice in which I was writing a string like this;
echo "This is an example string " >> outfile.txt
The character count is 32, and if you could see the break line character (chr(10)) the line would read;
This is an example string
If you unix2dos outfile.txt the line looks the same as above but with a different break line character. However when you place the file into Kedit and save it, now the character count is 25 and the line looks like this;
This is an example string
This occurs because Kedit does not preserve spaces at the end of a line. It places the return or line break character at the last letter or "non space" character in a line.
So programs that read literal input like DIPS (i'm guessing) or more widely used AutoCAD scripting will have a real problem with extra spaces before the return character. Basically in AutoCAD scripting a space in a line is treated as a return character. So if you have ten extra spaces at the end of a line it's treated the same as ten returns instead of the one you probably intended.
OH and if this helped you out or though it was good please give me a vote up!
unix2dos converts the line-break characters at the end of each line, from unix line breaks (10) to dos line breaks (13, 10)
Kedit could possible change the encoding of the file (like from ansi to UTF-8)
You can change the encoding of a file with the iconv utility (on a linux box)