I am trying to add a DKIM Record to my DNS and i noticed that I have to split the entry due to the 250 something character per line limit. I am using Ubuntu 14.
When I split the text do I have to use ";" or "," between v=DKIM1; k=rsa;?
When I use ";" the text after the symbol change color like it is comment in vi editor.
Any clue why this is happening or what I should choose?
If your DKIM exceeds 255 characters you should split it into strings surrounded by double quotes:
"v=DKIM1; k=rsa;"
"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4TWhAkE9cQBB7g2C6jGb
4jdiaShZEtWBkupXFtBdOdJTvrMTAEPIhZske9+bp/ILDYbWG0Tzw7DcmWoTPF+J
bNDH4mN8hSy1pPxyxsmvtFqr5bMlaWl42arkWR3Zzq9A/ReMcEfZ5avwP2JubH72"
"Bg0SP6NNfrUD9sAWtzOIAt1rT1UygohlB+2EdeHdWFN9neHHDN/hVzL82qufuMZ0
bOAHyn/kuT9hK0HkHc+vHTGIloPlhr6siNfmGwU/Lmv7d7uY/YFpvMvZrl90Fu77
5J7944VNMp6E7tGlJjlt01zDGa5QH1K1funRdrObLxxMgq0Z7RMx5GD5CHMS4tRn
eQIDAQAB"
All this should be put into the same TXT record, like so:
mail._domainkey.example.com IN TXT "v=DKIM1; k=rsa; MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4TWhAkE9cQBB7g2C6jGb4jdiaShZEtWBkupXFtBdOdJTvrMTAEPIhZske9+bp/ILDYbWG0Tzw7DcmWoTPF+JbNDH4mN8hSy1pPxyxsmvtFqr5bMlaWl42arkWR3Zzq9A/ReMcEfZ5avwP2JubH72" "Bg0SP6NNfrUD9sAWtzOIAt1rT1UygohlB+2EdeHdWFN9neHHDN/hVzL82qufuMZ0bOAHyn/kuT9hK0HkHc+vHTGIloPlhr6siNfmGwU/Lmv7d7uY/YFpvMvZrl90Fu775J7944VNMp6E7tGlJjlt01zDGa5QH1K1funRdrObLxxMgq0Z7RMx5GD5CHMS4tRneQIDAQAB"
or if you want it split in multiple lines, you can do it with brackets
mail._domainkey.example.com IN TXT ("v=DKIM1; k=rsa;"
"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4TWhAkE9cQBB7g2C6jGb4jdiaShZEtWBkupXFtBdOdJTvrMTAEPIhZske9+bp/ILDYbWG0Tzw7DcmWoTPF+JbNDH4mN8hSy1pPxyxsmvtFqr5bMlaWl42arkWR3Zzq9A/ReMcEfZ5avwP2JubH72"
"Bg0SP6NNfrUD9sAWtzOIAt1rT1UygohlB+2EdeHdWFN9neHHDN/hVzL82qufuMZ0bOAHyn/kuT9hK0HkHc+vHTGIloPlhr6siNfmGwU/Lmv7d7uY/YFpvMvZrl90Fu775J7944VNMp6E7tGlJjlt01zDGa5QH1K1funRdrObLxxMgq0Z7RMx5GD5CHMS4tRneQIDAQAB")
Concerning vi, if you're editing your zone files with vi it recognizes that it is a zone file and changes color because ; is indeed used as a comment character, but it shouldn't color if semicolon is between quotations...
Related
I am trying to remove a newline characters from with in quotes in file
I am able to achieve that using the below code
awk -F"\"" '!length($NF){print;next}{printf("%s ", $0)}' filename.txt>filenamenew.txt
Note I am creating a new file filenamenew.txt is this avoidable can i do the command in place the reason I ask is because files are huge.
my file is pipe delimited
sample input file
"id"|"name"
"1"|"john
doe"
"2"|"second
name
in the list"
using the above code I get the following output
"id"|"name"
"1"|"john doe"
"2"|"second name in the list"
but I have a huge files and i see in some of the lines have ^M character in between quotes example
second sample input file
"id"|"name"
"1"|"john
doe"
"^M2"|"second^M^M
name
in the list"
o/p using above code
"id"|"name"
"1"|"john doe"
name in the list"
so basically if there is a ^M in the line that string is not being printed but i read online ^M is equal to \r so i used
tr -d'\r'< filename.txt
I also tried
awk-F"|"{sub(/^M/,"")}1
but it did not remove those characters (^M)
A little background on why i am doing this
I am extracting data from a relational table and loading into flat file and checking if the counts between table and file matched but since there is \n in columns count(*) vs wc-l in file is not matching.
final resolution:
i don't want to delete these unprintable characters in the long run but want to replace it with some character or value(so that counts between table and file matches) and then when i am loading it back to a table i want to again replace the value that i have added effectively as a place holder with \n or ^M what was originally present so that there is no tampering of data from my side.
Any suggestions is appreciated.
thanks.
I am attempting to split a large 200,000 line csv file into smaller pieces using the terminal command:
split -l 20000 users.csv
From what I have read online this should chop up the 200,000 line csv into ten 20,000 line files but this doesn't happen. All I get is a text file called 'xaa' that is just the original csv, all 200,000 lines.
Like I said in the title I am running on Mac OS High Sierra v.10.13.5
What exactly am I missing here?
As Ken Thomases points out in the comments, the most likely culprit is that the file is using non-newline line separators, and the most likely culprit is CR (carriage return).
You can tell if this is the case using the file utility. A file with such line separators looks like this:
$ file foo
foo: ASCII text, with CR line terminators
The reason split would behave this way with those line separators is that the file would appear to be only one line long (no newline characters). So split would write that one (very long) line, then exit.
you should use the split command with the -b option. This will split your files based on kilobytes or megabytes. This may break up a line at the end but can manually be accounted for.
I have a rather tricky request...
We use a special application which is connected to a oracle database. For control reasons the application uses special characters which are defined by the application and saved in a long field of the database.
My task is to query the long field periodically and check for changes. To do that, I write the content by using a bash script in a file and compare the old and the new file with md5sum.
When there's a difference, I want to send the old file via mail. The problem is, that the old file contains these special characters and I don't know how to replace them with for example a string which describes them.
I tried to replace them on the basis of their ASCII code, but this didn't work. I've also tried to replace them by their appearance in the file. (They look like this: ^P ) This didn't work neither.
When viewing the file by text editor like nano the characters are visible like described above. But when using cat on the file, the content is only displayed until the first appearance of such a control character.
As far as I know there is know possibility to replace them while querying from the database because of the fact that the content is in a LONG field.
I hope you can help me.
Thank you in advance.
Marco
^P is the Control-P character, which is decimal 16 or hexadecimal 0x10, also known as the Data Link Escape (DLE) character in ASCII.
To replace all occurrences of 0x10 in a file with another string we can use our friend gsed:
gsed "s/\x10/Data Link Escape/g" yourfile.txt
This should replace all occurrences of characters containing the hex value 0x10 with the text string "Data Link Escape". You'll probably want to use a different string - this is just an example.
Depending on the system you're using you may be able to use the standard sed command if your version of sed recognizes the \xNN single-character escape codes. If there are multiple hex characters you need to replace you may want to create a file containing your sed commands, one for each hexadecmial character you need to replace, and tell sed or gsed to use the commands in the file - consult the sed or gsed man pages for how to do this.
Share and enjoy.
You can use xxd to change the string to its hex representation, then use xxd -r to convert back.
Or, you can use uuencode and uudecode.
One option is to run the file through cat -v. This replaces nonprinting characters with visible representations (using the ^ notation for control characters):
$ echo $'\x10\x12\x13\x14\x16' | cat -v
^P^R^S^T^V
we want to switch to Putty at work, but we have one big problem: in error situations we have to copy some lines from our logfile (using less/vi and mouse copy & paste). These lines can be 32 KB long and contain several blanks, the blanks need to be preserved. Unfortunately, if the copied content is wrapped because it doesn't fit in one line in the window, Putty seems to replace the trailing blanks with a newline character.
e.g. if we have the line (with trailing spaces that need to be preserved -> you see the trailing spaces if you select the example):
LINE START, WINDOW IS 80 CHARACTERS WIDTH, BUT LINE IS 32KB
SO LINE IS WRAPPED IN THE PUTTY WINDOW
THE TRAILING SPACES NEED TO BE PRESERVED....
BUT USING PUTTYS COPY & PASTE, PUTTY REPLACES SPACE CHARACTERS BY NEWLINE
...LINE END
and we copy & paste, we get (select second example):
LINE START, WINDOW IS 80 CHARACTERS WIDTH, BUT LINE IS 32KB
SO LINE IS WRAPPED IN THE PUTTY WINDOW
THE TRAILING SPACES NEED TO BE PRESERVED....
BUT USING PUTTYS COPY & PASTE, PUTTY REPLACES SPACE CHARACTERS BY NEWLINE
...LINE END
Putty cuts the trailing spaces and inserts a newline character. Can this behaviour be configured/changed in Putty?
Thank you,
Christian
I have used non-breaking spaces to retain trailing whitespace when copying/pasting from PuTTY. My application was ssh-ing into a linux box and copying/pasting some code using the Bourne shell, so I don't know how widely this will work in other environments.
To insert a non-breaking space, hold the Alt key and type 255, then release the Alt key. The following example can be used for testing. For some reason, the code doesn't retain the non-breaking space when I copy/paste directly from this webpage, so you will need to test it this way:
a. Copy/paste the code below into notepad
b. Delete the space in blank=" "
c. Insert a non-breaking space with Alt+255
d. Copy/paste the code into PuTTY
e. Copy/paste the output back into notepad to view results
CODE
# non-breaking space, Alt+255
blank=" "
# regular space
space=" "
echo "
blank:$blank
space:$space
"
Which outputs a trailing space for the $blank var, but not for the $space var.
OUTPUT
blank:
space:
I'm not sure that Putty can do it but in my case (putty working on redhat open client) I converted source files to unix format (dos2unix command).
Now pasting works fine.
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)