Here is a preliminary version of a uuencode module for tcllib inclusion. There are two entry points. uuencode::encode and uuencode::decode just encode or decode the input data while uuencode::uuencode and uuencode::uudecode will generate a properly formatted message (lines limited to 67 chars, length encoded into the first character). [PT] This is now part of [Tcllib] in the base64 module as uuencode package. So : % package require uuencode 1.0 % uuencode::encode ABC 04)# % uuencode::decode "04)#" ABC % set data [uuencode::uuencode -name sample.dat ABC] begin 644 sample.dat #04)# ` end % uuencode::uudecode $data {sample.dat 644 ABC} % ---- See the code at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tcllib/tcllib/modules/base64/uuencode.tcl?rev=HEAD&content-type=text/vnd.viewcvs-markup ---- [FPX] The uuencoding format has a troubled history. There is no formal specification for uuencoding, and while it was a de-facto standard throughout the 90's, implementations have varied wildly in realizing some of the format's subtleties. This includes variations in line lengths, extra "parity" characters at the end of each line, and the encoding of '0' as either the space character (in which case spaces at the end of a line may be truncated) or the tilde. It gets worse when you consider possibilities for splitting uuencoded files across multiple messages. Using a "fair-weather" package like uudecode may have a suboptimal success rate for decoding real-life messages, when used without preprocessing. (Shameless plug: [uudeview] was written to handle many of the more terminal cases.) These days, the use of uuencoding is decreasing. In E-Mail messages, it has been almost fully replaced by [MIME]. It remains in lesser, but still active use in newsgroup, along with [MIME] and [yencode] (which has its own share of problems, not unlike uuencoding). New software should refrain from using uuencoding but for legacy purposes. ---- See also [uudecode] [Category Package], subset [Tcllib] - [Category File]