Unzipping: The "End of Line" symbol for users of Unix or Macintosh


Back to The Economics Pack.
Nowadays, this installation uses *.zip files. That should cause no problems for Unix or Macintosh. 

Use:

unzip -aa TheEconomicsPack.zip


For the use of the -aa option, see

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/unzip.1.html

"MODIFIERS
       -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 zipinfo listings, rather than `b') to be automatically extracted  as  such,  con-verting converting
              verting  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 perfect; 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, regardless of the supposed file type."
---

However, if, and that is is big if, such problems still arise, then the following might still be relevant. 

In the past, this installation used the *.tar.gz format for Unix or Macintosh. This caused a problem for the "end of line" character. 

The notebooks and packages have been developed under Windows. This may create problems for users of Unix or Macintosh with the "end of line" character. The following note explains what you can do. (But again, this problem should not arise under the use of *.zip.)

1. Explanation
Windows, Unix and Macintosh each use different characters to mark the end of a line:
Windows     ^M^J  (control-m, control-j)
Unix             ^J       (control-j)
Max             ^M     (control-m)
Many programs that transfer files from Windows machines to Unix machines automatically strip out the control-m characters. If you use FTP (in text mode), the control-m characters would be eliminated. That is, if you used FTP on a single notebook or package. In the case where you download the whole zipped file, that would be different.

(Conversely, if I would use FTP to put my notebooks on the web, and if my provider has a Unix machine, then such stripping would occur. But this also might depend upon whether I use textmode or binary mode.)

2. Solution using Perl for a single file
If you have the perl programming language installed on your Unix host (typically /usr/local/bin/perl) then you can convert a Windows-based text file into a Unix-based text file with the command:
perl -p -i -e "s/\r//g;" filename
(This suggestion came from Alan DeGuzman, Technical Support, WRI October 16 1995)
3. Solution using dos2unix for all files
Unix users can use the program dos2unix that is is freely available from a number of websites. The following command, run in the Economics directory of The Economics Pack, should do the job of starting from that directory downwards, it finds all files, excluding directories, and runs dos2unix on them:
find . -type f -exec dos2unix {} \;
(This suggestion came from Ritesh Sood, Graduate Student, Dept. of Electrical & Computer Eng.,  Department of Mathematics, University of California, Davis, May 8 2005)
4. Another solution using dos2unix for all files
Another solution is to use http://www.tcl.tk/about/dos2unix.html

This solution originally broke down due to an empty Dump directory, yet, in the present version of the Pack this Dump directory now is filled with a Readme.txt file.

(This suggestion came from Richard Gill, 2008)