THE HACKER'S DICTIONAIRY

Click HERE to download "The Hacker's Dictionairy". Rare Ebook. Visit Me Again for more collections like this.

Set up Gmail to work with Thunderbird (IMAP)

Thunderbird 2.0

Note: if you're using an older version of Thunderbird, we highly recommend upgrading to version 2.0.
To set up your Thunderbird client to work with Gmail:
1. Enable IMAP in Gmail.
2. Open Thunderbird, and select Tools > Account Settings.
3. Click Add Account.
4. Select the Email account radio button and click Next. The Identity screen appears.
5. Enter your full name in the Your Name field. Enter your full Gmail email address (username@gmail.com) in the Email Address field, and click Next.
6. Select IMAP as the type of incoming server you are using. Enter imap.gmail.com in the Incoming Server field.
7. Set the Outgoing Server to smtp.gmail.com, and click Next.

8. Enter your Gmail username (including @gmail.com) in the Incoming User Name and Outgoing User Name fields, and click Next





9. Enter a name for your email account in the Account Name field, and click Next.
10. Verify your account information in the dialog box, and click Finish.
11. Select Server Settings from the folder list below your new account.
12. Update the Port value to 993.
13. In the Security Settings section, select SSL from the Use secure connection options.
14. Select Check for messages at startup and Automatically download new messages
15. Click Outgoing Server (SMTP) in the folder list



16. Select the smtp.gmail.com (Default) entry from the list and click Edit. The SMTP Server page appears.
17. Enter smtp.gmail.com as the Server Name and set the Port to 587.
18. Select User name and password and enter your Gmail username (including @gmail.com) in the User Name field.
19. Select TLS from the Use secure connection radio buttons and click OK.
20. Click OK to save your changes and exit the Account Settings dialog.

adjust your client's settings as needed.
* Did you click 'Save Changes' after enabling IMAP in Gmail? To ensure that Gmail can communicate with your mail client, be sure to click Save Changes on the Forwarding and POP/IMAP settings tab.

IMPLMENTING QUIRKS

Implementation Of Quirks

Function X doesn't seem to work on Perl for Win32. Why not?

There are several functions that are unimplemented in the Perl for Win32 system. Primary among these are alarm() and fork(), which are used in quite a lot of modules developed for UNIX. Because they're missing in Perl for Win32, you can't use those modules.

Other unimplemented functions include System V IPC functions, UNIX system calls, Berkeley sockets functions that aren't WinSock functions, and some other weird ones. Here's a list, as extracted from unsupported.ntt, the perl script that tests unimplemented functions to make sure they stay that way and don't spontaneously implement themselves:

    alarm(), chroot(), fork(), getpgrp(), getppid(), getpriority(),
   getpwnam(), getgrnam(), getpwuid(), getgrgid(), getpwent(),
   getgrent(), setpwent(), setgrent(), endpwent(), endgrent(), kill(),
   link(), msgctl(), msgget(), msgrcv(), msgsnd(), semctl(), semget(),
   semop(), setpgrp(), setpriority(), shmctl(), shmget(), shmread(),
   shmwrite(), symlink(), syscall(), times(), wait(), waitpid(),
   getnetbyname(), getnetbyaddr(), getnetent(), getprotoent(),
   getservent(), sethostent(), setnetent(), setprotoent(), setservent(),
   endhostent(), endnetent(), endprotoent(), endservent(), socketpair()

Many other functions act in unexpected ways or are poorly implemented. Here is a (definitely non-exhaustive) list:

• mkdir: The second argument, MODE, is ignored.
• stat: UNIX-specific measurements such as blocks, inode, gid, and uid are returned, but undefined.

[Others? -ESP]

Function Y doesn't seem to work under PerlIS. Why not?

Besides not being a UNIX program, PerlIS has the second disadvantage of sharing a process space with the Web server and any number of other ISAPI extensions. Because of this, there are further restrictions on what a Perl script run by PerlIS can and cannot do. Some are built in, and some are just "bad" things to do.

According to the PerlIS info page, there are two things you can not/should not do in a Perl script run from PerlIS:

• change the current working directory
• spawn another process, using backticks (``), the system() or exec() functions, Win32::Spawn() or any of the Win32::Process functions

What's the difference between Perl for Win32 and the standard distribution?

Oh, a whole lot. The standard distribution was developed and is maintained in a UNIX-centric world, and there are a lot of OS dependencies built in. Here's a short list of the differences:

• The standard distribution's build procedure depends on UNIX shell scripts and make files not applicable to the Win32 world.
• Many UNIXish functions, modules and scripts are either unavailable, flaky, or just plain broke in the Perl for Win32 implementation.
• The standard distribution is in source form; Perl for Win32 is in binary and source form.
• Documentation for the standard distribution is in POD format; documentation for Perl for Win32 are in HTML format.
• Most standard tools that UNIX perl programmers employ in their scripts without a second thought (such as "sendmail") are not available on Windows NT. Even fewer are available on Windows 95.
• The difference between binary and text files under Win32 matters, which it doesn't for UNIX. inary files can get mangled by treating them like text files.
• Files and drives are addressed differently on Windows platforms than on UNIX. In particular, each drive has a letter (like "C:"), and directories in a path are separated by "\" rather than "/".

Finally, there's a difference in culture. perl is developed and maintained by the people who use it, and there's a collaborative nature to the progress of that product. Conversely, Perl for Win32 is de facto owned by ActiveWare, which has neither the participatory nature of a loose-knit user-developer community nor the responsiveness of a commercial software company.

What's the difference between running Perl for Win32 on Windows NT versus running it on Windows 95?

Although Perl for Win32 originally did not run on Windows 95, there should now be little difference between the two operating systems. You should watch for the following, though:

• The command interpreter for Windows NT, cmd.exe, is different than the command interpreter for Windows 95, command.com. command.com has some archaic ways of taking arguments and returning error codes that don't jibe with cmd.exe. ActiveWare has developed a work-around program, cmd32.exe, which will take the place of cmd.exe on Windows 95 for executing programs from a Perl script.
• The Win32::NetAdmin, Win32::NetResource, and Win32::EventLog modules will not run on Windows 95.
• Some functions that work on Windows NT reportedly do not work or are buggy on Windows 95. An example is flock().
• Finally, many helpful programs that are available on Windows NT are not there on Windows 95. "hostname", for example, is not available on Windows 95. [Others? -ESP]

[Other differences? -ESP]

If you're worried about using a feature from one or the other, check the result of the function Win32::IsWinNT() to see what OS you're running on.

Why don't my examples from the Camel book work?

The Camel book (aka _Programming_Perl_, Wall et.al., O'Reilly & Associates 1996) was written by UNIX people for, in general, UNIX people.

Some of the examples in the Camel book will work. Some will not. If they fail, it's because either the functions used are not available, the external tools used are not available, or the modules used are not available. Usually, for small scripts, it's not to hard to fiddle with them until they come out correct (

Camel and Llama books are good learning tools. However, one of the things you learn as a Perl for Win32 programmer is how to port UNIX-targeted scripts and modules to Perl for Win32. So, get used to it.

The Perl motto is "There's More Than One Way To Do It." The Perl for Win32 motto could be "It's A Good Thing That There's More Than One Way To Do It, Because Most Of The Ways Don't Work."

5.6. Why doesn't standard library module Z work?

Many of the standard library modules don't work for the same reason that other Perl code doesn't work: the functions aren't implemented, the external tools aren't present, or modules they depend on aren't available.

Many of the "standard library" modules that come with the perl 5.00x standard distribution aren't distributed with the Perl for Win32 distribution because they weren't around for perl 5.001m. So, use'ing those modules may not even be possible.

How do I make a UNIX-based script work?

First, make extra-super sure that you are using the script or module in the way it was intended. Many of us are quick to blame the module, the operating system, or the interpreter when, in reality, it is our own code that isn't working right.

If you're sure that it's not a problem in your code, the best way to make a UNIX-based script work is to desk-check it before running it. Look for some of the following things:

• Calls to functions unimplemented in Perl for Win32.
  
• Calls to standard library modules or CPAN modules that aren't available on Perl for Win32, or that don't work.
• system() or backtick (``) calls to system tools that aren't available on Perl for Win32.
• Reading and writing files that may be binary.
  
• File-system dependent path names and path name parsing. Watch for "/" rather than "\\", and hard-coded UNIX paths like "/usr/lib".
• Version require's, like "require 5.003;" or "require Sockets 1.03;". Check to see if the script or module really requires the new version.

Of course, it should go without saying that for everything you take out you'll have to put in a work-around.

Once you've worked around UNIX dependencies in the script or module, try running it through the debugger to see if what you did helps. If the script or module comes with a ".t" test file, try using that to test your changed version.

If you _do_ make a change to a UNIX-based script or module, please let the author know. They will sometimes be gracious enough to make changes that will let the program run on Perl for Win32. If the author won't change the program, ask if you can make the altered version available to other users.

How does the chmod function work on Win32 platforms?

chmod() will execute as expected in Perl for Win32. However, it may not have the results you want. [Can someone tell me what works and what doesn't? -ESP]

UNIX-style security for files is not applicable to files on Win32 systems. Win32 systems inherit from DOS four possible "file attributes": archived (A), read-only (R), hidden (H), and system (S). These can be checked and set with the Win32::File::Get/SetAttributes().

Windows NT systems using NTFS can also have more specific permissions granted on individual files to users and groups. In build 110, you can retrieve and set these by running the CACLS program (type HELP CACLS at the command line for details). For builds 300 and above, you can use the Win32::FileSecurity module to maintain file permissions.