egisin@Math.Waterloo.EDU (Eric Gisin @ University of Waterloo) (05/21/87)
I'm trying to document the variations of uuencode format, and would like to acknowledge the various authors. Here is what I've figured out; if there are errors could someone let me know? The original version was written by someone at Berkeley. It was enhanced with an "encoding table" and the ability to restore missing trailing blanks to avoid problems over RSCS. I believe this is called the Dumas version. It was further enhanced to optionally split the output by JPHD. Does anyone know the full name of these authors, or of any other enhancements to the "standard". I'll be posting a portable version of the enhanced version with full documentation in the future. Eric Gisin, University of Waterloo InterNet [CSNet/UseNet]: egisin@Math.Waterloo.EDU dumb UUCP: watmath!egisin
W8SDZ@SIMTEL20.ARPA (Keith Petersen) (05/23/87)
Frank Wancho added another enhancement to uuencode - a trailing "M" at
the end of each line - which seems to eliminate the problem of mailers
lopping off trailing spaces. The extra character at the end of the
line is ignored by uudecode because it's one greater than the number
of characters it's looking for.
Some IBM systems seem to change the spaces into backwards appostrophy
(`) so uudecode should look for those and treat them as if they were
spaces.
Another recent enhancement to uuencode/uudecode is adding a checksum
to the end of each line - something that has been badly needed for a
long time! I'll dig up that version and send it along for your
consideration.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie Mail: W8SDZ
RCP/M Royal Oak: 313-759-6569 (300, 1200, 24lllegisin@orchid.waterloo.EDU (Eric Gisin) (05/24/87)
I've heard of all of those enhancements, but don't have a copy of the checksum version. It's not IBM systems changing ' ' to '`', 4.3 BSD uuencode does that (to get around the trailing space problem).
john@viper.UUCP (05/26/87)
In article <7702@orchid.UUCP> egisin@Math.Waterloo.EDU (Eric Gisin @ University of Waterloo) writes: > >The original version was written by someone at Berkeley. >It was enhanced with an "encoding table" and the ability >to restore missing trailing blanks to avoid problems over RSCS. >I believe this is called the Dumas version. >It was further enhanced to optionally split the output by JPHD. >Does anyone know the full name of these authors, >or of any other enhancements to the "standard". > Eric, JPHD is Jean-Pierre H. Dumas the author of "the Dumas version". His full autograph/address follows: +--------------------------------------------------+ | Jean-Pierre H. Dumas | | | | network@frsac11 (bitnet) | | network%frsac11.bitnet@wiscvm.wisc.edu (arpanet) | | ..!ihnp4!frsac11.bitnet!network (usenet ?) | | dumas@sumex-aim.stanford.edu (arpanet) | +--------------------------------------------------+ >I'll be posting a portable version of the enhanced version >with full documentation in the future. I would recommend contacting Jean-Pierre to chat about the enhanced version, your version, and subjects related to portability... :-) I think JPHD is planning to release a new version sometime soon to solve a few problems encountered with en/decoding files from/to other versions of UUENCODE/UUDECODE. The changes may prove useful. --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
langdon@lll-lcc.aRpA (Bruce Langdon) (05/28/87)
In article <1046@viper.Lynx.MN.ORG>, john@viper.Lynx.MN.ORG (John Stanley) writes: > In article <7702@orchid.UUCP> egisin@Math.Waterloo.EDU (Eric Gisin @ University of Waterloo) writes: > > > >The original version was written by someone at Berkeley. > >It was enhanced with an "encoding table" and the ability > >to restore missing trailing blanks to avoid problems over RSCS. > > > >...any other enhancements to the "standard". > > atob and btoa are part of the compress package, freely available. btoa makes a more compact encoding than uuencode. Does it have trouble with weird (IBM etc) sites? If you use compress first, you REALLY save on the size of your ascii file to transmit. ---------------------------------------------------------------------- Bruce Langdon L-472 langdon@lll-lcc.ARPA Physics Department 339650%d@nmfecc.ARPA Lawrence Livermore National Laboratory Livermore, CA 94550 (415) 422-5444 UUCP: ..{ihnp4,qantel,ucdavis,pyramid,styx,topaz}!lll-lcc!langdon ..{gymble,ll-xn,seismo}!lll-crg!lll-lcc!langdon
dfk@mcvax.UUCP (05/28/87)
In article <886@lll-lcc.aRpA> langdon@lll-lcc.aRpA (Bruce Langdon) writes: ^^^^ asking for trouble, eh? > ... >btoa makes a more compact encoding than uuencode. Does it have trouble >with weird (IBM etc) sites? > ... I have sent some KB via BITNET using tar cf - tosend | compress | btoa | mail user@host.bitnet So far it has worked fine crossing VM, MVS and VMS sites on the way. The newer versions of compress also have a shellscript called tarmail that makes this easier by splitting the result up for you. Daniel Karrenberg Future Net: <dfk@cwi.nl> CWI, Amsterdam Oldie Net: mcvax!dfk Because It's There Net: DFK@MCVAX -- Daniel Karrenberg Future Net: <dfk@cwi.nl> CWI, Amsterdam Oldie Net: mcvax!dfk Because It's There Net: DFK@MCVAX
david@a.ms.UKy.CSNET (David Herron E-Mail Hack) (05/28/87)
> In article <1046@viper.Lynx.MN.ORG>, john@viper.Lynx.MN.ORG (John Stanley) writes: > > In article <7702@orchid.UUCP> egisin@Math.Waterloo.EDU (Eric Gisin @ University of Waterloo) writes: > > > > > >...any other enhancements to the "standard". > > > > atob and btoa are part of the compress package, freely available. > btoa makes a more compact encoding than uuencode. Does it have trouble > with weird (IBM etc) sites? If you use compress first, you REALLY save > on the size of your ascii file to transmit. > ---------------------------------------------------------------------- > Bruce Langdon L-472 langdon@lll-lcc.ARPA > Physics Department 339650%d@nmfecc.ARPA > Lawrence Livermore National Laboratory > Livermore, CA 94550 (415) 422-5444 > UUCP: ..{ihnp4,qantel,ucdavis,pyramid,styx,topaz}!lll-lcc!langdon > ..{gymble,ll-xn,seismo}!lll-crg!lll-lcc!langdon First, atob/btoa were not in the compress distribution which was included with 4.3BSD. No problem for me because we already had it and had been using it for months. But I'm sure someone out there is missing it. Second. I've been using compress and btoa to transmit Usenet news over BITNET for about a year now. It works fine except for a couple of bugs. One strange one was a condition where there would be a blank line between the end of the encoded data and the trailer record. Some part of BITNET was adding blanks to the line to make sure it didn't disappear because it was a null record. The atob part didn't like the blanks and got confused. -- ----- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet ----- (also "postmaster", "news", and the Usenet map maintainer for Kentucky.) ----- bsmtp-users@ms.uky.csnet for bsmtp discussion ----- bsmtp-users-request@ms.uky.csnet for administrivia
egisin@orchid.UUCP (Eric Gisin) (05/29/87)
I'll admit atob is better that uuencode, but there is a lot of existing archived software in uuencode format. The problem with bitnet (in addition to stripping trailing blanks) is that lack of a standard for ascii/ebcdic translation on systems that need to translate between them (Unix, VMS, and TCP/IP on VM and MVS). (you would think the Bitnet people could adopt a standard and encourage its members to adopt it). There is an enhancement to uuencode that includes an encoding table at the beginning so that any one-to-one mis-translations can be reversed when decoding. (atob could enhanced likewise).
meissner@dg_rtp.UUCP (05/30/87)
In article <886@lll-lcc.aRpA> langdon@lll-lcc.aRpA (Bruce Langdon) writes: /* stuff about uuencode/uudecode deleted */ > atob and btoa are part of the compress package, freely available. > btoa makes a more compact encoding than uuencode. Does it have trouble > with weird (IBM etc) sites? If you use compress first, you REALLY save > on the size of your ascii file to transmit. One thing to note about atob/btoa is that will append upto 3 (or 4?) null bytes upon conversion from printable chars to binary. Compress evidently can handle it, but I was surprized when I was using them without compress. -- Michael Meissner, Data General Uucp: ...mcnc!rti!dg_rtp!meissner It is 11pm, do you know what your sendmail and uucico are doing?
mouse@mcgill-vision.UUCP (06/09/87)
In article <1999@dg_rtp.UUCP>, meissner@dg_rtp.UUCP (Michael Meissner) writes: > In article <886@lll-lcc.aRpA> langdon@lll-lcc.aRpA (Bruce Langdon) writes: >> [recommends using atob/btoa rather than uuencode/uudecode] > One thing to note about atob/btoa is that will append upto 3 (or 4?) > null bytes upon conversion from printable chars to binary. You must have a broken atob (or btoa, or both). % echo -n x | btoa | atob | cat -v x% echo -n xx | btoa | atob | cat -v xx% echo -n xxx | btoa | atob | cat -v xxx% echo -n xxxx | btoa | atob | cat -v xxxx% No nulls anywhere. der Mouse (mouse@mcgill-vision.uucp)