You didn't tell us which shell you are using. I don't know if your construction works in bash, but in ksh it won't:
typeset -A comp1=$(cat file1 | cut -d"|" -f2)
will produce an array with exactly one element from your files, as "typeset -A" uses whitespace as delimiter, not newlines. You will see that when you trace the script with "set -xv" and watch the output of "(cat file1 | cut ...)".
Then there is a logical error in your code: the "for str in .... done" cycles through every element of the array comp2[]. You compare each to every element of comp1[]: comp2[1] to comp1[1], then comp2[1] to comp1[2], ..., comp2[1] to comp1[n], comp2[2] to comp1[1], comp2[2] to comp1[2], ... This is probably not what you want to achieve - you want to compare comp1[1] to comp2[1], comp1[2] to comp2[2], etc. This is done by the following (demo-)code:
(( count = 0 ))
while (( count < ${#comp2[*]} )) ; do
if [ "${comp2[$count]}" != "${comp1[$count]}" ] ; then
print - "line $count is different"
else
print - "line $count is equal"
fi
(( count += 1 ))
done
If you want to *search* in one file for the key you found in the other and don't rely on them being sorted according to the same key then do the following: cycle through one array, searching through the other one. If you find a corresponding value store the number of the array-element found. If this number is not stored you have not found a corresponding element. Again, in a sketchy demo-code:
(( count1 = 0 ))
(( count2 = 0 ))
(( found = -1 ))
while (( count2 < ${#comp2[*]} )) ; do
(( count1 = 0 ))
(( found = -1 ))
while (( count1 < ${#comp1[*]} )) ; do
if [ "${comp2[$count2]}" != "${comp1[$count1]}" ] ; then
(( found = count1 ))
fi
(( count1 += 1 ))
done
if [[ $found -lt 0 ]] ; then
print - "no corresponding element to ${comp2[$count2]} found"
else
print - "element ${comp2[$count2]} corresponds to ${comp1[$found]}"
fi
(( count2 += 1 ))
done
Most SQL tables have a key field or fields. Normally the key field would be used to identify and match the record to determine if it has changed. But from your requirement, this is not what you are looking for.
Also, normally SQL queries do not guarantee the order of records unless the order by clause is used. So, without order by, the same query executed twice could, theoretically, return the same records in two totally different orders.
True. Even if the files are not ordered it would be possible to pipe them through "sort" (man sort) to get them sorted prior to searching them. This would limit the search-effort too, because at some point one could be sure that no matching record will follow.
Hey bakunin n kahuna
thanks a ton
i think i got to change my codes n look for other approach
as pointed by both of u rightly
"Also, normally SQL queries do not guarantee the order of records unless the order by clause is used. So, without order by, the same query executed twice could, theoretically, return the same records in two totally different orders."
there is no guarantee that order of records would be same ...
so simply matching row wise ... would not generate desired result
Dana, I don't think your problem is in your input files - your problem is in your approach. You should *analyze* your requirements, make a plan how to implement them and only then write a program. The real knowledge you need to acquire is not "do i lay a brick here or there?" but "how does the house i want to build look like?".
Lets start over: you tell us, what you want to achieve and which data you have got. Then we help you develop a plan to derive the data you want from the data you have. Finally - but only after this step - we implement the plan into real existing software.
Sorry for becoming a little theoretical here, but you are having a very common problem among system administrators here: just because a program (yes, a script is a program like every other) might be short doesn't mean the way software engineers (real software engineers, not the itsy-bitsy mouse-pushers with their 5D - 6GL - graphical - object- blabla - tools) organize their work:
understand your goals (the goals of your customer)
organize what you have got to work with
define your requirements
make a plan to get from where you are to where you want to be
only then put this plan to work by writing the software
If you read the whole thread from the beginning it is like you ask how to change the tires of your car. It turns out, though, that your problem is not a tire, but your car doesn't work any more for reasons unknown and you just *think* that might have something to do with the tire needing to be changed. So you don't need to know hoe to change the tire but you need to find out the reason why your car won't go anymore - maybe its the tire, but maybe its something completely different. Lets get back to this step otherwise you might end up with a car with four brand new tires which still won't go because the gearbox is broken.
What a thread !
Interesting read and as bakunin has suggested it isn't the tire.
My impression from reading the thread is that Dana's kinda asking for a "dynamic" comparrison (if there is such a thing).
Especially when Dana mentions:
But I still consider myself a novice so I'll end my rant here.
As I believe this would indeed add content to this thread i am going to answer here instead of writing a PN to you:
real software engineers write programs
"other" / "not real" software engineers use graphical tools to create input for other graphical tools, which have symbolical output, which is fed to pseudo-generators, which create pseudocode for other generators, which generate code for other generators, which finally generate program code, which is fed to a compiler and then run. Don't ask, why a "Hello-World"-program takes 20 minutes to load and needs a minimum of 16GB RAM to run - RAM is cheap anyways, right? And the process is very object-oriented, streamlined, hyper-ultra-anything, turbo-accelerated, and so on and so on.
Of course they (the second type of "software engineers") do not need to analyze anything - they just shuffle the mouse around, click on the most colourful icon and - done (or so). That the users of this b*sh*t are often using some Excel worksheet to keep track of the list the program was written to provide in first place - just a minor issue. It may not fulfill its purpose, but it definitely is easy to use, easy to adapt (it can easily be brought to not do other things equally slow), etc., etc., blather, blather, ...
I hope i have made my point clear. I may sound bitter, but i have administered too many SAP-systems to find these things still funny.