ac@utgpu.UUCP (08/06/87)
I recently downloaded the AR command to my OS9 system but when I tried to UUDECODE it I had a problem. THe UUDECODE I was using was NOT the one recently posted but rather one I had ported from elsewhere some time ago. The version I have seems to be a close relative of the version recently posted since many of the lines of C code are identical. The problem is that my version of UUDECODE seems to expect an extra field between 'begin' and the file name field in the uuencoded file. It actual ignores this field but it does require it to be present. My version of UUENCODE always uses the value '644' after 'begin' When I edited 644 into my download of ar.uue, my uudecode worked fine. I gather the 644 has something to do with file permissions in the original UUENCODE/UUDECODE and for some reason can't be handled easily under OS9. The trouble is that several UUDECODEs including mine die if this field is missing. It will be inconvenient having several incompatible forms of UUENCODing around. I realize of course that the UUDECODE just posted will work correctly with the UUDECODE just posted. But as it stands I will have to have 2 versions of these utilities. Would it not be better to go with the idea of using a dummy permission of 644 as a placeholder and repost a version of these utilities with that modification? -- Name: Mark Acfield (University of Toronto Computing Services) Path: ihnp4!utgpu!ac Alias: ac@utoronto.bitnet
ac@utgpu.UUCP (09/16/87)
Subject: uuencode/uudecode This is a reposting of a comment I sent after downloading Pete Lyall's uuencode/uudecode. I received no reponse at that time so perhaps it got lost in the mail. At any rate since Pete is about to post some stuff using these utilities I thought I might repost my comment. ------------------------------------------------------------------ I recently downloaded the AR command to my OS9 system but when I tried to UUDECODE it I had a problem. THe UUDECODE I was using was NOT the one recently posted but rather one I had ported from elsewhere some time ago. The version I have seems to be a close relative of the version recently posted since many of the lines of C code are identical. The problem is that my version of UUDECODE seems to expect an extra field between 'begin' and the file name field in the uuencoded file. It actual ignores this field but it does require it to be present. My version of UUENCODE always uses the value '644' after 'begin' When I edited 644 into my download of ar.uue, my uudecode worked fine. I gather the 644 has something to do with file permissions in the original UUENCODE/UUDECODE and for some reason can't be handled easily under OS9. The trouble is that several UUDECODEs including mine die if this field is missing. It will be inconvenient having several incompatible forms of UUENCODing around. I realize of course that the UUDECODE just posted will work correctly with the UUDECODE just posted. But as it stands I will have to have 2 versions of these utilities. Would it not be better to go with the idea of using a dummy permission of 644 as a placeholder and repost a version of these utilities with that modification? ----------------------------------------------------------------------- p.s. Pete..please don't delay any of your posings to resolve this problem. I can certainly live with 2 uudecodes for now and would much rather get the TSEDIT patches. -- Name: Mark Acfield (University of Toronto Computing Services) Path: ihnp4!utgpu!ac Alias: ac@utoronto.bitnet
jimomura@lsuc.UUCP (09/19/87)
Mark pointed out that an early version of Uuencode/Uudecode for OS-9 didn't support the Unix file attribute field. I think a later version of Uuencode posted by Pete did in fact support this field. I'll have to check my downloads to make sure of this because mine is still in my backlog files, but if you want me to check for you send me Unix mail. We're in the same city, so it's cheaper for me to send it locally than to have another Net posting. Also, I think it's an easy enough change that I'd rather not see the whole file posted again. Most of us have C compilers don't we? (Some of you may even be using them -- which I can't due to my current system configuration. :-) Cheers! -- Jim O. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
pete@wlbr.EATON.COM (Pete Lyall) (09/22/87)
In regard to Marc Acfield's posting regarding UUENCODE/UUDECODE
and the absent 'mode' (begin filename 644) stuff...
Er -I did hack that stuff in, recompile, and (ulp) repost it weeks
ago. I am hoping that the majority of you got the revised versions
of UUEN/DECODE. It *ignores* the mode, but puts it there on encode and
skips over it on decode. If enough folks fail to get it, I will
repost.
BTW - Makpatch/Ipatch utilities and the Tsedit patches (to be used
with the former) are on their way. Thanks to Bob Santy (at Charles
River Data - he's listening!) for these fine offerings!
--
Pete Lyall
Usenet: {trwrb, scgvaxd, ihnp4, voder, vortex}!wlbr!pete
Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)