I am trying to send an array that is [2 x N] doubles large to a text file using the fprintf() command. I am having problems in that fprintf() is not recognizing the new line command (\n) or the carriage return command (\r). The code I am using is
fid = fopen([Image.Dir,'CtlPts_',Image.Files{k},'.txt'],'w');
fprintf(fid,'%.4f\t%.4f\n',control_points{k});
fclose(fid);
where the data I am trying to print is in the cell control_points{k}.
The tab gets printed fine, but everything in the text file gets printed on one line, so this is why I am assuming that it is ignoring my new line character.
Is there something wrong with my syntax that I am not seeing?
I know that on many systems, \n is not enough to create what you're asking for (and so, maybe you have to do \r\n)
An alternative solution is to open the file in text mode, that way MATLAB automatically inserts a carriage return \r before any newline \n character in the output on Windows systems:
fid = fopen('file.txt', 'wt');
fprintf(fid, '%f\t%f\n', rand(10,2));
fclose(fid);
Note that this is somewhat unnecessary, since most editors (with the exception of Microsoft Notepad) recognize Unix/Mac/Windows line endings.
Related
Has anyone any idea why the following would format itself in a weird way? In several years I've had no problem with creating simple text output but this problem has me baffled.
I'm using the line
print "$BC,$Ttl,$FN,$SN,$Finalage,$OurLoc,$OurDT,$FinalPC\n";
Every value is a simple text string on which I've run "chomp" to remove return characters.
I would expect the output to look like the following:
*DD10099999,,Information Services,Guest Ticket 2,41,C G,03/11/2020,NE8 9BB*
$BC is the first item and $FinalPC is the postcode at the end.
Instead I get:
*,NE8 9BB99, ,Information Services,Guest Ticket 2,41,C G,03/11/2020*
The final item has somehow moved to the beginning of the line and overwritten the first item. This is happening consistently on every line of my screen and text file output and I'm completely stumped as to why. The data is read from a text file and compared with database output which is also simple text. There are no occurrences of \b anywhere in my code. Why would a backspace character get into it?
The string in $OurDT ends with a carriage return, which causes your terminal to home the cursor. Presumably, the value of $OurDT came from a Windows file read on a unixy machine.
One option is to fix the file (e.g. by using the dos2unix utility).
Another is to accept both CRLF and LF as line endings (e.g. by using s/\s+\z// instead of chomp).
I have a strange behaviour in Matlab dealing with RTF files.
The rtf file is read with this instruction:
cin = textread(filename, '%s', 'delimiter', '\n');
(cin) is a Nx1 cell where N is the number of rows of the file,
so I can edit some specific row.
I write the file RTF with the function below:
function dum= cell2rtf(cin, filename)
[row, col]= size(cin);
fout= fopen(filename, 'w');
for ii=1:row
if(ii<row)
fprintf(fout, '%s\r\n', cin{ii});
else
fprintf(fout, '%s', cin{ii});
end
end
fclose(fout);
The strange behaviour is this one:
If the row cin{x} is a string with content
'19°\cell 19°\cell \cell \cell \cell 70°'
the same row appears like below when the file is written by the function
'19°\cell 19°\cell \cell \cell \cell 70°'
I can't understand why the char '°' becomes '°' in every occurrence
and I'd like to know how this can be corrected.
The problem is that textread() works on plain text files, and RTF files are not plain text files: they are binary-ish files that contain markup and formatting codes, sorta like Word .doc files. textread() is probably encountering those formatting/structural codes and misinterpreting them as plain text characters, and that's where your junk characters like  are coming from.
Could you just save your RTF file as a plain text file and read from that?
Otherwise, you'll need to write an RTF parser or find an RTF parsing library and use that. Matlab works (kind of) easily with Java libraries, so you could use the Apache Tika library's RTFParser or RTFParserKit.
I am trying to output table data to a .dat file where I separate the rows by newlines and the column data by commas. I have this written for the first few rows:
fileID = fopen(strcat(filename,'.dat'), 'wt');
fprintf(fileID, '"","","","","","","",""\n');
fprintf(fileID, '"TIMESTAMP","RECORD","MuxAddress","Averages"\n');
fclose(fileID);
This should generate this text in the file:
"","","","","","","",""
"TIMESTAMP","RECORD","MuxAddress","Averages"
Unfortunately, the code actually generates this text:
"","","","","","","","",
"TIMESTAMP","RECORD","MuxAddress","Averages",
Which you can see has commas at the end of each line. This issue breaks a viewer program that I am using, and I can see no way to fix it. I have not found anyone else saying they have this issue either.
I have done some testing, and if I do a fprintf by itself with a newline, it does not put a comma, but as soon as I put a second fprintf, it creates commas at the end of both lines.
So it turns out that it all came down to file permissions. In the specific case with overwriting the file instead of appending it, the code would add the commas. I never discovered WHY the commas were being added, but I did find that if I appended the file instead of overwriting they went away.
I run into this one while trying to parse a text file with Perl. The original file looks like this in vim:
When I tried to print the 2nd column (87 here), somehow, the ^M showed up in vim:
I'm just curious what this "^M" is? Does anyone know? Thanks!
^M is ASCII character 13, known as a carriage return. MS-DOS uses a carriage return followed by a line feed (ASCII 10) to mark the end of a line. Unix systems use a line feed only. Usually you will "see" a carriage return when using an editor that thinks your file is using Unix style line endings but actually has MS-DOS style line endings.
I am using the fprintf command to store the contents of a .mat file to a .txt. The .mat file contains strings. My code prints the data in the same column.
fid = fopen('exp.txt','wt');
for i=1:275
fprintf (fid,classes{i}{1})
end
fclose(fid);
When I use the \n and the '\r\n' options, they doesn't print anything to the file. I'd appreciate the help!
Some text editors will show those new line characters and some wont. This happens because of different standards followed by different softwares and operating systems for eg:
end of line sequences
Windows end of line sequence: \r\n
Unix end of line sequence: \n
Mac end of line sequence: \r
So if you really want good human readable formats, either fix your operation system/software and use characters friendly for that system, or if you want uniformity in the reports, better write files in standard HTML formats :)
adding a "br" tag and naming file .html is as simple as writing out '\n' and naming it .txt!