So I have over 100 text files, all of which are over the size required to be opened in a normal text editor (eg; notepad, notepad++). Meaning I cannot use those mentioned.
All text files contain the same format, they contain:
abc0001:00000009a
abc0054:000000809a
abc00888:054450000009a
and so on..
I was wondering, how do I replace the ":" in each of those text files to then be "\n" (regex for new line)
So then it would be:
abc0001
00000009a
abc0054
000000809a
abc00888
054450000009a
How would I do this to all of the 100 text files, without doing this manually and individually. (if there's any way?)
Any help is appreciated.
You can use sed. The following does something similar to what you want. The question concerns Unix, but a lot of Unix utilities have been ported to MS Windows (even sed): http://gnuwin32.sourceforge.net/packages/sed.htm
UNIX: Replace Newline w/ Colon, Preserving Newline Before EOF
Something like (where you provide your text file as input, and the output becomes your new text file):
sed 's/:/\n/g'
Related
given a file formatted as markdown occasionally interspersed with blocks of PGP, how can I strip out the PGP blocks using standard linux tools in a shell script?
The file looks like this gist
(I had to create a gist because of formatting issues)
Using sed you can do that:
sed '/^-----BEGIN PGP/,/^-----END PGP/d' file
In short: you define a range of lines between two patterns /pat1/,/pat2/ that are deleted (d).
In BBEdit (v11.6), when I search for the "\r" character in a txt file previoulsy saved as "Unix (LF)" from the "Save as..." dialog, the result is the end of each individual line of the file.
Why?
The BBEdit hex dump correctly shows that no CR (OD) chars are present in the file.
From the 11.6 release notes:
BBEdit now uses the line feed (ASCII decimal 10) as line breaks in its internal representation for text in open documents, instead of the carriage return (ASCII decimal 13) that was the standard Mac format for many years. This (theoretically) reduces the time required to open documents, since in the normal case, no conversion is necessary; it also eliminates conversion logic when copying and pasting text, since LF-delimited text is also the standard interchange format on the Clipboard.
As before, you may use \n and \r interchangeably in search strings and Grep patterns. (The latter usage is for compatibility with old versions of BBEdit.)
I am exporting some Access tables to txt files and there are a lot of problems with the txt file. One of those problems being line breaks not visible in the txt file itself. If I copy a line with a line break into Notepad++ from Notepad, it'll break into 2 lines.
So I believe this may be a code format problem, but I can't find the proper one to resolve this. I'm currently exporting to the default Western European, but should I export tot UTF, Unicode, ASCII or something else?
When exporting from MS Access (or VB/VBA in general), make sure you're using vbCrLf constant (Carriage Return plus Line Feed) for line breaks. That constant corresponds to HEX values 0D 0A.
In Windows, it is a convention to use the above 2 characters together as line breaks, while in many other platforms, such as Unix/Linux/MacOS/etc. typically just 0A is used.
That brings up an issue: Notepad, the standard Windows text file viewer, cannot deal with 0A alone and does not treat such symbols as line breaks. More advanced editors, such as Notepad++ or UltraEdit, display such files correctly, though.
The CSV export function in Microsoft Office applications (Excel, Access) terminate a data row with CR+LF and write for a line break within a data value (multi-line string) just LF into the file. (I think just CR was written into the CSV file for a line break in older versions of Office before Office 2007.)
Most text editors detect those LF without CR (respectively CR without LF) and convert them to CR+LF on loading the CSV file which results on viewing of the CSV file in text editor in supposed wrong CSV lines as number of data values is not correct on data rows with data values containing a line break.
However, newline characters within a double quoted value in a CSV file are correct according to CSV specification as described in Wikipedia article about Comma-separated values.
But most applications with support on import from CSV file do not support CSV files with newline characters within a double quoted value and therefore some data values are imported wrong. Also regular expression replaces can't be done on a CSV file with newline characters within a data value because the number of separator character is not constant on all lines.
UltraEdit has for editing such CSV files with only LF (or CR) for a line break within a data value a special configuration setting. At Advanced - Configuration - File Handling - DOS/Unix/Mac Handling the option Never prompt to convert files to DOS format or Prompt to convert if file is not DOS format with clicking on button No if this prompt is displayed must be selected and additionally Only recognize DOS terminated lines (CR/LF) as new lines for editing must be enabled.
The CSV file with CR+LF for end of data row and only LF (or CR) for a line-break within a data value is loaded with those settings in UltraEdit with number of lines equal the number of data rows. And the line-feeds without carriage return (respectively the carriage returns without line-feed) in the CSV file are displayed as character in the lines with a small rectangle as no font has a glyph for a carriage return or line-feed defined because they are whitespace characters with no width. A Perl regular expression find searching for \r(?!\n)|\n(?<!\r) can be used now to find those line breaks within data values and replace them with something different like a space character or remove them.
Which character encoding (ASCII, ANSI, Unicode (UTF-16), UTF-8) to use on export depends on which characters can exist in string values. A Unicode encoding is necessary if string values can have also characters not included in local code page.
How can I extract the "cell" information from an RTF file using SED (bash shell). ie all the character strings between any pairs of { }, of which there can be several on a line of RTF. I want to strip out all the RTF code and just keep the table values.
This might work for you (GNU sed):
sed '/{/!d;s/[^{]*{\([^}]*\)}/\1\n/;P;D' file
It deletes any line that does not have an opening brace. Then removes any characters upto and including the first opening brace. Then prints the string(s) within but not including the closing brace on a separate line.
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!