A little habit:
If you were to haunt me, every so often you would see me open up a
new terminal window, run
cat >/dev/null', and paste or type something there.
What I am doing with this peculiar behavior is simple: I'm arranging for a slightly more persistent text storage than my X selection. I park any number of things depending on what I'm doing; snippets of text from fishing back in editor undo, commands that I'm temporarily re-running, and so on.
There's nothing particularly special about
cat in a terminal window
for this. There's any number of other programs and ways that I could do
this; it's just that this way is the fastest and most convenient in my
environment. Your environment is probably different, especially if you
keep an editor going all of the time (if I always had Emacs running, I'd
probably just paste things into a scratch Emacs buffer).
xclipboard should be ideal for this. In practice it
sadly doesn't work out, partly because its version of cut & paste is
significantly worse than that of terminal programs.)
Note that in some ways using a terminal window is a bad idea. I always have to make sure that any tabs are unimportant, because they're probably going to turn into spaces by the time I paste the text back into its eventual destination.
(I would really like an X terminal program that was smart enough to preserve tabs, but I haven't run into one yet.)
On (not) putting IP addresses in registration email
If you are creating some sort of system that sends email to people in response to web-based requests, it is tempting to think that you should put in the IP address (and the timestamp) that the request came from, in case your services are abused. In practice this is useless, for a number of reasons.
The first one is that almost no one sends abuse complaints about spam any more, because people have long since worked out that doing so is almost always a waste of (their) time. If your system is used to spam people, they're just going to arrange to block you (in one of many different ways, often by clicking some 'report as spam' button).
Related to this is that what you are actually giving people is second hand evidence, and that is plain not very useful for abuse complaints. Imagine that you are an abuse department and you get a report that says, more or less, 'someone else sent me spam, but claims that it came from one of your IP addresses at this time'. Are you going to do very much with that complaint? Well, no, for all sorts of reasons.
(Also, let me gently point out that these days anyone who is going to use your system to harass someone with subscription requests is going to do it through open proxies.)
As mentioned before, one of the reasons that such second hand evidence is not very useful is that it has been faked over and over again by spammers themselves, because spammers just love to claim that they're not responsible for the spam, no, really. At this point such claims are probably more likely to appear in spam than they are to appear in real email, and certainly they give your email messages a certain smell.
So in short, including IP addresses is useless in practice and makes your email look kind of spammy.
Finally, there is an issue of responsibility. To wit: if your system can be used to spam someone, it is your responsibility to fix it and to deal with it, not the recipient's. It is your job to take precautions, to be unattractive to spammers and harassers, to track and block IPs, and if necessary to send abuse complaints to ISPs. If you're doing all of this right, putting the request's IP address in the email is unnecessary.
Putting the IP address in your email messages anyways sends any number of signals to people. None of them are very good signals.