Can your mail client prompt you, if you forgot to attach a file?

How many times you have received any mail which says that there is a file attached, but there isn't any file attached. The sender has actually forgot to attach a file. Also, how many times you have sent such a mail?

Ya, things like this happens. So what could be the solution? Can we have a mail client intelligent enough to prompt us about missing attachment? Is this possible?

Looking at the problem, I can see a very simple solution. It goes like this:

Prompt user before sending a mail WHEN
the mail content HAS WORD like 'attached' or 'enclosed'
AND
there is NO attachment attached

Also, this check can only be performed, when user wants his mail client to prompt about missing attachment, by explicitly setting the related option in mail client preferences.

Looking at the mails I have received without attachments, and sometimes the delay caused because of that, I strongly feel that having such a feature will be really useful.

What's wrong with Sun Studio C++?

Don't be surprised if you are using multimap and your code is working on other standard C++ compilers and not on Sun Studio C++. e.g. See below code, which is correct according to C++ standards, but it will not compile on Sun Studio C++.

And if you use map instead of multimap it will work. But hey, you want to use multimap and not map, so what's wrong with Sun Studio C++?

#include <map>
#include <utility>

int main() {
std::map<int, int> mymap;
mymap.insert(std::make_pair(2, 4));

std::multimap<int, int> mymultimap;
mymultimap.insert(std::make_pair(2, 4));

return 0;
}


If you compile this code with Sun Studio (my version was forte v10.0p1), you probably will get error something like,

Error: Could not find a match for std::multimap<int, int, std::less<int>, std::allocator<std::pair<const int, int>>>::insert(std::pair<int, int>) needed in main().


The same code will compile perfectly fine with other standard C++ compilers. So, what's wrong with Sun Studio C++? Is something missing in Sun Studio?

OK, So to investigate it further, if you open <sun-studio-installation-directory>/prod/include/CC/Cstd/utility, you'll find

#ifndef _RWSTD_NO_MEMBER_TEMPLATES
template <class U, class V> pair(const pair<U,V>& p)
: first(p.first), second(p.second)
{ ; }
#endif

and in <sun-studio-installation-directory>/prod/include/CC/Cstd/stdcomp.h, you'll find

# define _RWSTD_NO_MEMBER_TEMPLATES 1


Since _RWSTD_NO_MEMBER_TEMPLATES is defined, member template copy constructor is not available. In case of map class it has function

pair<iterator, bool> insert (const pair<key_type, mapped_type> &__x)
{
return insert (pair<const key_type, mapped_type> (__x.first, __x.second));
}

therefore it works for map class.

In case of multimap, value_type is pair<const Key, T>, and since pair class lacks the templated copy constructor, insert can't convert pair<int, int> to pair<const int, int>, So we can use following work around:
1.

#include <map>
#include <utility>

int main() {
std::map<int, int> mymap;
mymap.insert(std::make_pair(2, 4));

std::multimap<int, int> mymultimap;
mymultimap.insert(std::pair<const int, int>(2, 4));

return 0;
}

2.

#include <map>
#include <utility>

int main() {
std::map<int, int> mymap;
mymap.insert(std::make_pair(2, 4));

typedef std::multimap<int, int> intmultimap;
intmultimap mymultimap;

mymultimap.insert(intmultimap::value_type(2,4));
return 0;
}

3.
If you don't want to change your existing code, you can use more standard-conforming library, by specifying option -library=stlport4, while compiling and linking.

Sun C++ FAQs indicates that they cannot update the standard library without breaking source and binary compatibility, so they will continue to ship a libCstd with the same limitations. I hope these workarounds will help you then.

diffing files in different way

The diff utility compares the content of file1 and file2 and writes to standard output a list of changes necessary to convert file1 into file2. diff may not be used when you want to find out which lines in file1 are not present in file2 and vice-a-versa.

Let's say you have a expected result's output file and a current result's output file,

expected-output.txt:
12 something some blah
15 ok ok and not ok
14 someone at somewhere
20 and many more such records

current-output.txt:
15 ok ok and not ok
13 this is not present in expected output
20 and many more such records

One quick way to do this is using power of Unix piping, sed, sort and uniq commands.

cat expected-output.txt | sed 's/^/expected-output.txt /g' > mixed.txt
cat current-output.txt | sed 's/^/current-output.txt /g' >> mixed.txt
sort +1 mixed.txt | uniq -u -f1 | sort

I would need to test this for files with really large number of records. But, currently I am satisfied with the above solution.

Don't take my stdin Mr. rsh

My colleague came to me and said "I have a script which reads a file line by line and doing some processing for each line, but strangely it is processing only the first line and exiting after that". I said "OK, I guess there must be something in your processing part that is eating all your stdin or a exit command for some condition. Let me see your script".

Just to give you an idea his script was something like this,

while read line
do
   # blah blah
   rsh <remote_server_name> ls /home/someone/something.txt
   # blah blah
done < input.txt

While I was looking at his script he said "When I comment this part, it processes all the lines and when I uncomment then it processes only the first line." OK, so what's there in that commented part. Bingo!, there is a rsh command. So, rsh seems to be a culprit.

After reading more about rsh, I found that rsh command cannot tell whether the remote program that it is going to run, need to read from stdin or not. Therefore, rsh copies stdin across the network to the remote program by absorbing ALL of the input (i.e. till EOF to know when to stop).

"OK, so you would need to store your stdin (which is mapped to input.txt) before executing rsh and restore it after that. Let us try something like this.", I said.

exec 4<&0
while read line
do
   # blah blah
   exec 5<&0
   exec 0<&4
   rsh <remote_server_name> ls /home/someone/something.txt
   exec 4<&0
   exec 0<&5
   # blah blah
done < input.txt

Somehow it didn't work. I am not sure why it didn't work. May be I would need to update this post once I find its reason. Then, I thought why don't we map /dev/null as stdin and let Mr. rsh eat that, and bingo! it worked.

exec 4</dev/null
while read line
do
   # blah blah
   exec 5<&0
   exec 0<&4
   rsh <remote_server_name> ls /home/someone/something.txt
   exec 4</dev/null
   exec 0<&5
   # blah blah
done < input.txt

My colleague was happy, because he got one more thing to mention in his weekly report :). I was happy too, for successfully helping and especially for learning something new by the process of that.

We should always help others, there is no better way to learn than that.