Screen shots

Security Notice
Phishing campain

This document is written for Windows users who may be having a problem reading or editing the SquirrelMail distribution. This distribution is basically a large set of text files which are run-time compiled by a web server which has PHP installed. The PHP interpreter will probably correctly handle files in any of the formats listed.

Here's the Problem

The line feed character <LF> is the standard end-of-line delimiter for text files on UNIX/POSIX/BSD systems. The end-of-line delimiter for text files on (classic?) Mac OS systems is a carriage return <CR>, and the end-of-line delimiter for text files on Windows and DOS systems is a carriage return followed by a line feed <CR><LF>. (I believe that Mac OS X is now based on FreeBSD's file system, and this would put it into the category of UNIX systems. This is only a hypothesis, as I do not have access to a Darwin/OS X system.)

Under Windows, you'll need your program that does un-tarring and gunzipping to make this change for you automatically (see Appendix 2), or Notepad will refuse to work for your files. (You will see all lines run together, with no possible way to wrap them properly.) Try WordPad if this is the case and it's too late!

There are probably converters that will batch a heap of these files through some sort of program that converts text files to Windows-style. This program can often be found under the name unix2dos; if you have sed (for example, from cygwin), that'll do it too. See the end of this page for a couple of commands to batch-convert these files. My FTP client will do this during an upload or download, but not at other times.

Sometimes, you may be stuck with all of your files in the UNIX-style <LF> condition. I know of two freeware programs you might like to use instead of Notepad/WordPad to edit these files. They're called the Programmer's Notepad and Source Edit. I found both at http://www.tucows.com/ or they might be found at http://www.download.com/ In each case, most PHP files are easier to edit because of the colors used to differentiate parts of the language.

If you're plain stuck, you could always open the file(s) in WordPad, select all, cut, and then paste into an empty Notepad document. Save the new file with Notepad, and rename it to the original document name. This will put <CR-LF> at the end of each line, as Windows expects. I had to do this when the program patch.exe crashed.

Appendix 1

Two scripts for cmd.exe/command.com and one for the wonderful Bourne shell, to convert *nix line endings to Windows-friendly ones.

First off, you will need the unix2dos command. There is one available which is based on the Windows Click method, for example, here: http://home.clear.net.nz/pages/niche/unix2dos.html This is not the unix2dos command needed in the script below.

And here is a web based version of unix2dos: [www.iconv.com]

But what you really need is the unix2dos command compiled for Windows that uses the commandline switches. You will need Cygwin or [MinGW]. The MinGW file you want is mingw-utils-0.3.tar.gz or later.

Given: unix2dos in the PATH, no files in the current directory except those to convert.

Does: converts each file $FILE to another file $FILE.crlf that has been converted to DOS-style line-endings

for %v in (*.*) do unix2dos < %v > %v.crlf

Given: same, but with sed

Does: same

for %v in (*.*) do sed -e 's/\n/\r\n/g' < %v > %v.crlf

Given: unix2dos, and sh/bash; otherwise as above

Does: nukes the originals and replaces them with their modified versions

for f in * do unix2dos < $f > _1_.tmp; rm $f; mv _1_.tmp $f; done

You can figure out the sed version yourself.

Appendix 2

The unzip utility available for every platform imaginable from [Info-ZIP] has some options to fix the <CR><LF> situation. For example, if you want to unzip a file zipped by a Windows machine file onto a UNIX/POSIX/Linux/BSD/GNU system, use the "-a" command switch:

unzip -a myzippedfile

This is from the man page for Info-ZIP's unzip:

-a convert text files.
Ordinarily all files are extracted exactly as they are stored (as ``binary`` files). The -a option causes files identified by zip as text files (those with the `t` label in zip- info listings, rather than `b`) to be automatically extracted as such, converting line endings, end-of- file characters and the character set itself as necessary. (For example, Unix files use line feeds (LFs) for end-of-line (EOL) and have no end-of-file (EOF) marker; Macintoshes use carriage returns (CRs) for EOLs; and most PC operating systems use CR+LF for EOLs and control-Z for EOF. In addition, IBM mainframes and the Michigan Terminal System use EBCDIC rather than the more common ASCII character set, and NT supports Unicode.) Note that zip's identification of text files is by no means per- fect; some ``text`` files may actually be binary and vice versa. unzip therefore prints ``[text]`` or ``[binary]`` as a visual check for each file it extracts when using the -a option. The -aa option forces all files to be extracted as text, regard- less of the supposed file type.

The same is probably true for GNU's gunzip, which is available in source code from [GNU.org] and seems to be available pre-compiled for Windows platforms at http://unxutils.sourceforge.net/ and http://mingw.sourceforge.net/. For gunzip, you can use the same -a option to convert text files to your computer's normal system.

gunzip -a myzippedfile

From the gunzip man file:

-a --ascii
ASCII text mode: convert end-of-lines using local conventions. This option is supported only on some non-Unix systems. For MSDOS, CR LF is converted to LF when compressing, and LF is converted to CR LF when decompressing.

So in case you already have messed up <CR><LF> stuff, you might need to zip and then unzip your files. See also [PK-Ware, Inc.], the makers of a commercial zip/unzip utility for many platforms.

© 1999-2010 by The SquirrelMail Project Team