Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!hellgate.utah.edu!csn!ub!acsu.buffalo.edu
From: cloos@acsu.buffalo.edu (James H. Cloos)
Newsgroups: comp.sys.handhelds
Subject: Re: Why ASC over UUENCODE?
Message-ID: <59467@eerie.acsu.Buffalo.EDU>
Date: 13 Feb 91 01:52:34 GMT
References: <1991Feb11.230500.9590@javelin.es.com> <37409@netnews.upenn.edu>
Sender: news@acsu.Buffalo.EDU
Organization: State University of New York @ Buffalo
Lines: 63
Nntp-Posting-Host: lictor.acsu.buffalo.edu

In article <37409@netnews.upenn.edu> hoford@sequoia.upenn.edu (John Hoford) writes:
>In article <1991Feb11.230500.9590@javelin.es.com> pashdown@javelin.sim.es.com writes:
>>
>>I am having a real hard time trying to see why ASC is preferred over UUENCODE.
>>Here are my points against ASC:
>
>>3. Not a standard form of transportation.  How many times are we going to see
>>"Where can I get ASC?" in the future?  UUENCODE is widely available FOR ALL
>>PC's.  UNIX, VMS, IBM, Amiga, Atari, Mac.  I think there is even an Apple II
>>version available.  If not, there are versions of UUENCODE available in
>>BASIC.
>
>But UUENCODE is not available for the hp48sx, the intended machine. 
>This seems to have been the major reason ASC was implemented,
>It also means you could not type in the binary progams.
>
>I my self would like them as uuencode'ed files.

For those who are interested, below is the format of uuencoded files.  I
know I said that I'd work on translating it to the 48, but I've been
flooded by rplc, a project for class (a Huffman encoding exercise) and
various other hw assignments, ergo: not uuencode/decode for the 48 from me
for a while!  If anyone else wants to try, it looks like this:

     Files output by uuencode(1C) consist of a header line,  fol-
     lowed  by  a  number  of  body  lines,  and  a trailer line.
     uudecode (see uuencode(1C)) will ignore any lines  preceding
     the  header  or  following  the  trailer.  Lines preceding a
     header must not, of course, look like a header.

     The header line is distinguished by having the first 6 char-
     acters  `begin  '.  The word begin is followed by a mode (in
     octal), and a string which names the  remote  file.   Spaces
     separate the three items in the header line.

     The body consists of a number of  lines,  each  at  most  62
     characters long (including the trailing NEWLINE). These con-
     sist of a character count, followed by  encoded  characters,
     followed  by  a  NEWLINE.  The  character  count is a single
     printing character, and represents an integer, the number of
     bytes  the  rest  of the line represents.  Such integers are
     always in the range from 0 to 63 and can  be  determined  by
     subtracting  the character space (octal 40) from the charac-
     ter.

     Groups of 3 bytes are stored in 4  characters,  6  bits  per
     character.  All are offset by a SPACE to make the characters
     printing.  The last line may be shorter than the  normal  45
     bytes.  If the size is not a multiple of 3, this fact can be
     determined by the value of  the  count  on  the  last  line.
     Extra garbage will be included to make the character count a
     multiple of 4.  The body is terminated  by  a  line  with  a
     count of zero.  This line consists of one ASCII SPACE.

     The trailer line consists of end on a line by itself.

(exerpted from uuencode.5 man page from SunOS 4.1.1 w/o perm.)

-JimC
--
James H. Cloos, Jr.		Phone:  +1 716 673-1250
cloos@ACSU.Buffalo.EDU		Snail:  PersonalZipCode:  14048-0772, USA
cloos@ub.UUCP			Quote:  <>