Unless both file1 and file2 are sorted by hash and salt and there is a one-to-one correspondence between lines in those two files, there is no chance that the command:
paste -d':' file1 file2
should be expected to work (and even in that case, those two fields would appear in the output twice).
You could consider using the join utility, but you would need to preprocess both input files so the key field used for joining is a single field (not two fields). If that won't work, awk would be the obvious choice. But, before we can suggest any real solution to your problem, you need to clearly define what should happen if:
there is no match in file1 for a pair of key fields found in file2 , or
there a more than one id field value in file1 for a single pair of key fields.
Please show us a representative pair of sample input files and the output that you want to produce from those sample inputs (each in CODE tags). (Please be sure that any cases that require special handling are included in your sample inputs.)
produces the output above from your sample input, but you ignored my note about preprocessing both input files to produce a single key field. The above command only compares the hash fields in the two files and completely ignores the salt fields when looking for matches in the two input files.
If the above output is acceptable but you need to match both the hash and salt fields, you might try using awk :
awk -F: '
NR == FNR {
id[$1, $2] = $3
next
}
($2, $3) in id {
print $0, id[$2, $3]
}' OFS=: file1.txt file2.txt > file3.txt
which also produces the output shown above from your sample input files.
If someone else wants to try this on a Solaris/SunOS system, change awk to /usr/xpg4/bin/awk or nawk .
How about posting the (curtailed) original files so people get the chance to analyse what might be going wrong? Not everybody's crystal ball can open and read your files remotely...
It is clear that join won't work for you with the data you are feeding it.
If you choose a field separator that also appears as data in a field, how is join supposed to guess at which field separator characters are field separators and which ones aren't?
Your sample input doesn't include any field separators in any of the sample hash fields. Your problem statement doesn't say anything about having to ignore some field separators nor does it describe any mechanism that could be used to determine the lengths of the various fields in your input lines.
It is not clear whether or not you will provide a clear enough description of your data for anyone to use any other tools to process your data. We clearly can't do so with the specifications you have provided us so far.