Slashdot Mirror
The Perl Cookbook, 2nd Edition
The new recipes cover a number of subjects. One of the prominent themes is how to use perl's new unicode support, as well as the new I/O layers feature. The coverage of web programming has definitely been fleshed out with recipes on XML-RPC, SOAP and so on, plus the new chapter on mod_perl. Also of interest of course are the additional recipes on database access with DBI.
The mod_perl chapter is a good succinct introduction, with some very cute recipes in it (though admittedly a lot of these are also covered in the excellent Mod_perl Developer's Cookbook by Young, Lindner and Kobes out from Sams). For example "Transparently Storing Information in URLs" shows how to embed information in any arbitrary position inside a URL. This quickly shows the kind of things you can do with a PerlTransHandler and a PerlFixupHandler. The chapter closes with what looks like a good introduction to "Template Toolkit", which I would probably be very excited about if I wasn't already familiar with the (also discussed) HTML::Mason.
I really enjoyed reading the XML chapter (a subject I'm less familiar with): I predict that you'll find this to be the fastest way through the XALPHABET XSOUP without drowning. For me, this was almost worth the price of the book.
Very little has been removed (hence the page count has gone from 757 to 927), and where I have been able to find a deletion, there are usually very good reasons for it. For example, the first edition takes the trouble to tell us that qr// was introduced in perl 5.005, but the new edition drops the babble about versions there, because for most of us, anything before 5.6 is now ancient history. However, I do miss this particular irrelevant parenthetic aside that's been deleted now:
Remember that the opposite of read is not write but print, although oddly enough, the opposite of sysread actually is syswrite. (split and join are opposites, but there's no speak to match listen, no resurrect for kill, and no curse for bless.)(p.295, first edition, compare to p.323, second edition.)
In general, it's difficult to think of anything seriously wrong with the Perl Cookbook. I might suggest that in some places they fall into the trap of talking about all the ways to do it, rather than just the best ways, (e.g. recipe 7.5 "Storing Filehandles into Variables" seems a bit complicated).
And maybe there are some slight problems with order of presentation, as with the new perl 5.8 feature of "I/O Layers", which is mentioned a few times before it's finally discussed in the beginning of Chapter 8 (though really, it's amazing that there aren't more problems like this: this is supposed to be reference work, and yet it usually works well as a tutorial also).
I've got one big complaint about the 2nd edition though: they changed the numbering of existing recipes! I've been writing code with comments like
# Schwartzian transform. See Perl Cookbook, recipe 4.15and now it turns out I should've been specifying an edition number also. Please: "Cookbook" authors, come up with a numbering scheme that remains invariant with new editions... if you can't always just append to the end of the chapter, there's nothing wrong with tacking another dotted decimal on the end. We're programmers, we can handle it.
And speaking of the "Schwartzian transform" that recipe has a very clear, self-explanatory name "Sorting a List by Computable Field", but in the first edition, there was also a footnote explaining that many people call this the Schwartzian Transform, named after Randall Schwartz, who invented the technique. With this second edition, that footnote has been quietly dropped. Guys, if you're going to carry on a feud, this is really not the way to do it. It just makes you look bad.
O'Reilly's perl.com site has a series of articles by the authors, featuring some recipes from the book:
Appendix: New recipes and examples (not including the two new chapters):
- Using Named Unicode Characters
- Treating Unicode Combined Characters as Single Characters
- Canonicalizing Strings with Unicode Combined Characters
- Treating a Unicode String as Octets
- Properly Capitalizing a Title or Headline
- Constant Variables
- Implementing a Sparse Array
- Creating a Hash with Immutable Keys or Values
- Matching Nested Patterns
- Writing a Subroutine That Takes Filehandles as Built-ins Do
- Storing Multiple Files in the DATA Area
- Reading an Entire Line Without Blocking
- Treating a File as an Array
- Setting the Default I/O Layers
- Reading or Writing Unicode from a Filehandle
- Converting Microsoft Text Files into Unicode
- Comparing the Contents of Two Files
- Pretending a String Is a File
- Working with Symbolic File Permissions Instead of Octal Values
- Writing a Switch Statement
- Coping with Circular Data Structures Using Weak References
- Program: Outlines
- Overriding a Built-in Function in All Packages
- Customizing Warnings
- Writing Extensions in C with Inline::C
- Cloning Constructors
- Copy Constructors
- Saving Query Results to Excel or CSV
- Escaping Quotes
- Dealing with Database Errors
- Repeating Queries Efficiently
- Building Queries Programmatically
- Finding the Number of Rows Returned by a Query
- Using Transactions
- Viewing Data One Page at a Time
- Querying a CSV File with SQL
- Using SQL Without a Database Server
- Graphing Data
- Thumbnailing Images
- Adding Text to an Image
- Program: graphbox
- Turning Signals into Fatal Errors
- Multitasking Server with Threads
- Writing a Multitasking Server with POE
- Accessing an LDAP Server
- Sending Attachments in Mail
- Extracting Attachments from Mail
- Writing an XML-RPC Server
- Writing an XML-RPC Client
- Writing a SOAP Server
- Writing a SOAP Client
- Program: rfrm
- Using Cookies
- Fetching Password-Protected Pages
- Fetching https:// Web Pages
- Resuming an HTTP GET
- Parsing HTML
- Extracting Table Data
You can purchase The Perl Cookbook, 2nd Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Referral: Amazon has this book for the same price as bn and with free shipping
The second edition works great for Perl 5.8. but not for Perl 6 which is going to require a rewrite of ALL of the Perl books.
O'Reilly addresses the issue here
Still Perl is such a beautiful thing you should buy ALL Perl books.
So, I've got perl scripts which may need to work on Unicode and non-ascii character sets somtime in the future. Today, I just test them with UTF-8, and it seems to work, but who knows if they really do work on those funny character sets? I can't read Kanji or other non-ascii characters. How can I test to see if they do work? Ideally, I'd like to have an xterm-like window that uses my standard keyboard to generate analogs to all my ASCII characters, but with some test encoding that puts them into some 16 bit character set range. This way, I can make sure that since we've gone to all this work to add Unicode support into our scripting languages that it does indeed work. Does anyone know how to test this?
Wow, I didn't know GOD had a slashdot account. I bow before thee, oh Great One.
Why not do this in the first place? Anyone who's written a university essay knows the importance of edition numbers. Page-numbering is particularly vulnerable, since even small clarifications will shift things around.
A different, and likely just as effecitive alternative, is to not specify the recipe number at all. Surely there's an index where you could look up "Schwartzian transform" without hard-coding the number.
- It's easy enough to get started, but takes years to get really good
- Doing it fast doesn't mean doing it well
- It's the little details that continue to amaze you
- You don't learn it from a book
Remember to actually use perl if you want to experience the bliss of perl.I have found www.perldoc.com quite useful for multiple versions of perl.
I haven't bought a technical book since I have moved out of the States - O'Reilly's Safari has been nice for that. I can still have access to their books.
I haven't looked to see if this new one is on there yet - I have the old version of it in paperback form as I do with pretty much all the other O'Reilly Perl books.
There are some odd things afoot now, in the Villa Straylight.
Like learning any new language (and the regular expression syntax IS a sublanguage into itself) the best way to learn it is to actually work with it for a while.
After a little hands-on work, you'll start to understand the logic behind all the line noise, and once you get to that point, the pure beauty of regexes and what they can do becomes clear.
In a way, it's a little bit like learning to program assembler. At first, all those opcodes are just a confusing mess, but once you get the hang of it, it starts to become clear.
DG
Want to learn about race cars? Read my Book
Read man pages and practice a lot as everybody else.
Very little has been removed (hence the page count has gone from 757 to 927), and where I have been able to find a deletion, there are usually very good reasons for it.
Correct me if I am wrong but I seem to remember that the first edition had quite a few errors (both syntactic and semantic). I'm guessing that the second edition has cleared all these up. However, when I try to access the errata for the first edition I can't find it! Surely support for previous editions doesn't "end" upon publication of newer editions. It is O'Reilly afterall...
After a period of time the regex parasite eventually wraps its tentacles around your brain stem, bending you to its will. This has the superficial appearance of understanding, but it's actually just shooting your brain full of mind altering substances to keep you docile. Regexes are something that you're infected with or not. Most of the people who are (like myself) wouldn't try to parse text without the nifty shortcuts it provides. The occasional squirt of dopamine is nice, too.
Error: PANTS NOT FOUND. Press <F1> to continue.
I know it's flamebait, but I would point out that one thing that Perl and Python let you do that sed/awk/grep don't is deal with networking. There once was a project to reimplement all the standard Unix utilities in Perl. Without debating the wisdom of doing so, I would like to know how you could implement an FTP server in awk.
On the other hand, I'll admit that I never learned Perl because everything that I needed to implement could, indeed, be done with awk and sed--they are quite powerful for text processing, but it's important to realize that they have limitations.
You mentioned you're a physicist -- how do you remember all those rules and formulas? The same principle applies. Writing regular expressions isn't complicated. It just takes time to learn well, like anything else. And "learning stuff by heart" is just rote memorization -- even animals can do that.
-toomuchPerl
It's true that people writing in Perl tend to use regular expressions in places where they're not necessarily appropriate. For instance, algorithmically speaking, subsequence matches are faster than regular-expression matches. (This is why Python has the .startswith and .endswith string methods, and the in operator.) However, the Perl regular-expression engine (PCRE) is optimized to heck and its raw speed can usually overcome this.
That said, the traditional regular-expression syntax is rather arcane. The only real alternative I've seen is the S-expression syntax of cl-ppcre -- the Common Lisp PCRE implementation. This allows you to write complex regular expressions as tree structure rather than as strings of character glyphs.
For instance, in place of the regex string "(?:foo)|(?:bar)|(?:b(a|(?:uz))z)" you can write:
Now, that might not be any clearer to you if you don't know Lisp, but it gets better as the regex gets more complicated. (I've been a little tricky by putting a lot of ?: in the original regex string. That's the code for "I want to do grouping, but I don't want to capture groups into variables." In the Lisp syntax, you have to mark when you do want capture, not when you don't. People writing in Perl usually let their groups get captured even when they don't make any use of the resulting variables.)
Interestingly enough, the authors of cl-ppcre claim that it outperforms Perl -- a remarkable claim, but they seem to have pretty comprehensive statistics as to when it does and when it doesn't. It's odd to think that even though many people think Lisp is slow, compiled Lisp can really be quite speedy for tasks that people usually use a specialized language for.
of the cookbook. Hell, keep the electronic version in a text file somewhere. There have been at least a couple of times I've finished writing a script, then I've looked in the Cookbook and found a better-written solution.
It's unique in that it doesn't just tell you about specific language properties. It actually gives a problem, a solution, and an explanation.
Perl 5 regular expressions are quite similar to regular UNIX regular expression, which should make your learning curve smoother. IAW, simple stuff is like UNIX, you'll just have to learn the advanced stuff if you want to use it. This is pretty much in line with perl's philosophy of making easy things easy and difficult things possible.
That would be the Perl Power Tools project.
Regardless of the religious wars over languages, I have time and again found Perl to simply be the most practical language for the job and continue to enjoy using it for a variety of tasks and watching it mature.
There is no substitute for the CPAN or Perl's ability to get the job done quickly and easily with an active community providing free (and very effective) support. Both Perl and the Perl Cookbook are an integral parts in my toolkit and for anyone who uses it, whether from time to time or regularly, I recommend it.
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
My problem with perl isn't perl itself. I have a fundamental understanding of the language, and a pretty good idea of where its niche is and what it can do for me.
I just don't have any projects!
I want to learn perl, but writing up half-hearted mock scripts doesn't teach you the same way as using it (or any language, package, device) to fulfill a certain need.
I'm also concerned about having to re-learn perl all over again when Perl6 is released.
do() || do_not();
But I guess it's convenient to think of everything that happens as being the result of a feud and ignore inconvenient facts like the "Schwartzian Transform" name still being mentioned in the long entry on sort function in Programming Perl, 3ed, which Tom also cowrote. Hmm, maybe I shouldn't point that out--now I'll be accused of having a feud with Randal!
--Nat
I dont know about FTP but here is a http server written in awk.
Enjoy!
As you would have guessed if you heard me speak in 2000, I'm not the biggest XML user. I've mellowed since then, but I still don't do a lot of XML hacking. (One of the spare-time hacking things I've while here at O'Reilly, though, is to get our internal database of "what books are at what stage" into XML for easy grepping and reuse).
Of all my work in the 2nd edition of the Cookbook, the XML chapter is the one I'm proudest of. I'm really glad you like it. Thanks!
--Nat
If you have something important to do, use perl. If you don't, then use perl/Tk. Its easy to learn, and good for writing short, silly graphics apps that will run equally well (or poorly) in Linux or Windows.
Of course, in that case you alse need Mastering Perl/Tk
I was amazed when I first read about tchrist's power tools project. Thanks for the link. I noticed that all the dates were from '98/'99. Did someone declare it done, or is limbo?
- doug
I've worked as a Perl programmer for several years, and the only book I've ever needed is "PERL - from the ground up" by Michael McMillan.
It has among others a very handy reference to Perl's built-in functions, lots of regexp stuff and more.
For everything else there is www.
Will code a sig generator for food
FYI. Tom Christiansen (54829) used to post comments here. He stopped because of the crap associated with the story on the death of Richard Stevens. Search for Christiansen to read his parting words.
IIRC, then came karma.
What are you on about? One of the oft-heard criticisms of Perl 6 is that it's TOO structured. Just read the Apocalypses and Exegesises (correct my latin plurals here, if you like) and you'll see Perl 6 is really hot on structure.
/C++/Pascal?
The whole thing is an exercise in pseudo-computer science masturbation
You talk about it as if Perl operates on mysterious brand-new concepts. It's a pragmatic language. None of it is particularly unique to Perl. In fact, if you search Google for 'pragmatic programming' the Google directory link at the top is to Ruby, the language you seem to jerk off to.
All the switching between $, @ and % is really irritating
More irritating than having to jump several pages up your code to see variable declarations as in C
I'd rather know @blah is an array, and $blah is a scalar, than have to jump around code looking for ints, chars, and arrays. Of course, you could argue that we should be using a naming scheme for variables. But if so, that invalidates your point too. The @, $, % symbols are, semantically, the same as having variables called i_myint, a_myarray, etc. How hard is to learn a few symbols, anyway?
Face it, you're anti-Perl, and that's okay, but it doesn't make you the most objective person to say which features are worthwhile or not.
Web Hosting Reviews
It'd be pretty easy in GNU awk, which is the most advanced awk out there.
Jurgen Kahrs implemented socket IO in GNU awk around 1997. See Robbins' O'Reilly book "Effective Awk Programming" for more details, it's a great book (even though I think the name is lousy).
If the number of FTP commands you wanted to implement is K, I'd guesstimate you'd need about 30 + (K*2) lines of Gawk to implement a reasonably bulletproof FTP.
Gawk ships with most linux distros, but many of them are shipping outdated versions.
You N00B!!!
They were able to do this because they used inetd to listed to the port for incoming connections. I don't think it is possible to write a stand-alone http server in awk, as that would require some mechanism for listening to ports. If you add in Bash, you can make outgoing connections using built-in special files /dev/tcp/host/port, but I don't think Bash lets you listen to a port for incoming connections (I may be wrong on that).
The first edition was an essential purchase for me, but I find that I refer to the HTML version on the 'Perl CD Bookshelf' much more often than the paperback. Anyone who doesn't subscribe to Safari and wants to read the electronic edition of Cookbook 2 will have to wait until January, when it'll be included in the 4th edition of the Bookshelf.
For instance, in place of the regex string "(?:foo)|(?:bar)|(?:b(a|(?:uz))z)" you can write [...]
Dude, I realize your post is about knocking perl regexes, but there's no need to obfuscate what could just as easily have been written as:
foo|bar|b(a|uz)z
or, even more simply, as
foo|buzz|ba[rz]
if you did not want to capture the a|uz, since you didn't indicate that you wanted to do so in your Lisp expression. Your eyes can pick that last one up in one chunk, and there's no need to scan back and forth to remember what it's doing.
In any case, just because Lisp is parenthesis-happy doesn't mean perl regexes have to be.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
A good way to learn regular expressions is to get Python and do experiments with them in the interactive interpreter. That way you get immediate feedback, which is good for learning. According to the docs, Python's regular-expression syntax is "similar to those found in Perl"; so you could transfer your knowledge back to Perl (or just stick with Python, hehe).
PCRE stands for Perl Compatable Regular Expressions, its an implementation of Perl's regular expressions that is separate from Perl proper. Also, I doubt that python's .beginswith .endswidth string methods are any more efficient than Perl's $string =~ /^text/; or $string =~ /text$/; regular expressions. Anchored searches are the quickest.
I don't do lisp, so
Perl6 is a mistake (Score:0, Flamebait)
I'm rather partial to R. Schwartz's books on the topic, the "pearl" book, the "camel" book -- I've never been a fan of tchrist and the documentation he writes. I secretly suspect him of authoring the awful OOP chapter in the Camel book.
Back in the day the venerable "Perl 5 HOWTO" was the shizzy for doing stuff before there was a billion modules in CPAN to do pretty much everything. I still refer to it when I need to write a server from scratch, even though its probably five years out of date now.
To the author who was confused by regular expressions: Jeff Friedel's book on the subject is excellent.
/nova20
Sure, Laziness is a virtue and all that, but to cite a specific example, I looked up how to parse program options. All Cookbook has to say on the matter is to use GetOpt. This is fine, and is decent advice, until you realize that GetOpt is by no means a complete solution, as it doesn't handle special characters. I beat my head on this for too long before having to search around and learn a graceful way to parse @ARGV (being new). I would have appreciated a reminder that you don't have to stick with GetOpt, and there is in fact, MTOWTDI.
Lesson having been learned, I would like to save other neophytes the trouble.
Fighting the War on the War on Drugs.
http://smokedot.org/
But to answer your question about how do you remember all of that stuff, the only thing I can say is that you play with it and get it to do things. To take your example of emacs, yeah it doesn't make a lot of sense that you do a CNTRL p to go the the "previous" line (why not u for "up"?), but if you do it a lot the immediate feedback you get from the hitting that keyboard gesture eventually burns the meaning of it into your hindbrain.
Actually, I guess there's one more thing you can say: there's often an underlying logic behind the design choices that you start to percieve after awhile. Sometimes this "logic" is just a matter of historical echoes, because the current design will always imitate a previous design in some respects. In the case of perl, it's regular expressions have a lot of similarities to the regular expressions used by other, earlier unix utilities (grep, awk, etc). It was done that way on purpose: the idea was that if you were familiar with unix, perl should be easy for you to pick up, and that pretty much worked: perl is very popular with unix admins. (Though as I understand it, it often goes the other ways these days... people learn perl first, and then discover later that they learned alot about unix.)
I've (un)successfully used this to avoid learning both perl and python for some years. D'oh!
--
I understand that it uses inetd, but it is a very impressive feat of awkish skill to pull this off. It makes a great use of inetd, but you are right awk has no way of making network connections as its *only* (please dont kill me) a text parser. Inetd is arguably much more efficent then having to code by hand the networking parts of your program. I'm no perl expert but i would say a shell script and inetd would possibly make a faster web server than some perl script, but then again what do i know?
This formulation is quite logical, like Perl REs. You seem to be using the word 'illogical' to mean 'requires me to learn syntax and semantics' - a bit like expecting knowledge of how to cook to leap fully formed from book to brain... Not everything in this world is intuitive at first glance, but having used REs for a long time, I find they actually *are* quite intuitive now.
....But I can personally attest that Christiansen can be such a jerk that he can't even be approached when he is positively wrong. I pointed out a very specific bug in Perl back in the Perl 4 days which had not been fixed for weeks to him. He said it had been fixed and that I was a fuckwit for bringing it up again. Gave him code to show I could still do it. He called me a liar. I appealed to higher gods. He caught wind. Then started a campaign to squash me on comp.lang.perl.misc. That worked because of his unfailing followers. His parting shot to me was some shit about being more educated than me (seemed very proud to be able to speak a couple of languages other than English. This is an accomplishment for an American, I admit) and making money at Perl. Blah. Blah. I seriously thought this was someone spoofing the guy for the longest time, because when I met him at conference before this period, he was very forthright and pleasant. Actually, he seemed like a nice guy to hang with or maybe work for. Anyhow, I gave it a rest. Perl is just a fucking programming language. Linux is just an OS. I understand he has disappeared from USENET as well because of abuse from users, his unabiding dislike of Newbies, and lack of time in general. Anyhoodles, all programming languages and OSes suck. Some just suck less. Perl is one that sucks less. Linux is one that sucks less. Hrmph.
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
You mean, in case Slashdot gets slashdotted?
Ignorance killed the cat. Curiosity was framed.
Flamebait only because he's pointing out that Perl is a hack? Come on moderators, that comment was Insightful.
Karma: It's all a bunch of tree-huggin' hippy crap!
At least chemistry has an 'official correct way' to write any compound.
Even Larry wants you to use a dozen different methods to perform a single task.
Karma: It's all a bunch of tree-huggin' hippy crap!
Yeah, languages within other languages usually save time. If they didn't, they wouldn't be there in the first place.
:-/
It's funny how many people will bitch about regular expressions, but only a very few people bitch about something much uglier like XPath. Maybe it's just that not too many people have been exposed to XPath to complain about it yet.
Karma: It's all a bunch of tree-huggin' hippy crap!
Actually, it wasn't. It was a discussion of the ways people use regex in Perl, and of the only other regex notation I'm familiar with besides Perl's.
Did you know that there are thousands of people in the world who discuss all manner of differemces without "knocking" anything? For instance, when biologists who study insects meet biologists who study lizards, they do not rant at one another about whether lizards r0x0r and insects sux0r or vice versa.
Well yes, but I was using "foo" to stand in for any sequence. It was intended as an example of a more full regex syntax.Oh, and don't call me "dude".
noise (and not even on the same line). Does that mean it will be better to
use instead English-like symbols? No. Most
chemists and mathematicians would prefer
to use what they already have. They only ones
who actually complain are those who are just
started learning Physics, Mathematics, or Chemistry.
How do you remember all these symbols, is the
same how you remember all these words in the
English language. You learn them!
Did you know that there are thousands of people in the world who discuss all manner of differemces without "knocking" anything? For instance, when biologists who study insects meet biologists who study lizards, they do not rant at one another about whether lizards r0x0r and insects sux0r or vice versa.
...) in the CL-PPCRE expression when you use (...) in the PCRE expression.
I think your reply is a bit of an over-reaction. Never did I say you ranted, and there's no call to become condescending. "Knock" is a pretty mild term for criticism. I don't think it's out of line to say you are criticising PCREs, and specifically their syntax, when you say the syntax is "arcane" and use words like "clearer" and "better" when describing the syntax of Lisp expressions.
I'm not trying to start a flame war either. I just think that, in the interest of level-headed discussion, you should make fair comparisons.
It's funny that you invoke biological science. A biologist, when performing an experiment, tries to limit the changes between groups to one independent variable, as do all scientists.
When comparing the clarity of expressions in two different syntaxes, the syntax is your independent variable. It doesn't provide a valid comparison to introduce needlessly another variable by changing what the expression does.
Well yes, but I was using "foo" to stand in for any sequence. It was intended as an example of a more full regex syntax.
But in the Lisp sequence, "foo" is just a simple string. In the perl sequence, you use a grouping operator for no apparent reason.
The equivalent expression to the PCRE (?:foo) in CL-PPCRE is (:group "foo"), not "foo". The equivalent expression to the CL-PPCRE "foo" is the PCRE foo, not (?:foo).
Similarly, you don't use (:register
It may seem like I'm picking nits, but that's what syntax (and science) is all about -- details. When you're making a comparison of syntaxes, these things are important.
So, the point of my post is that you should compare apples to apples. To do otherwise is to use the techniques of the very r0x0r/sux0r trolls you decry.
Kitchen sinks are traditionally written in LISP and integrated into emacs :)
Those who can't do, teach. Those who can't teach either, do tech support.
I wasnt talking about speed efficeiency.
Have you tried Regexp::English?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
That said, the traditional regular-expression syntax is rather arcane. The only real alternative I've seen is the S-expression syntax of cl-ppcre -- the Common Lisp PCRE implementation. This allows you to write complex regular expressions as tree structure rather than as strings of character glyphs.
Sounds like Regexp::English, only less explicit.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)