Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!linac!uwm.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!msi.umn.edu!cs.umn.edu!cybrspc!roy From: roy%cybrspc@cs.umn.edu (Roy M. Silvernail) Newsgroups: comp.lang.perl Subject: Re: UUdecode question Message-ID: Date: 9 Dec 90 05:29:33 GMT References: Organization: Villa CyberSpace, Minneapolis, MN Lines: 20 roy%cybrspc@cs.umn.edu (Roy M. Silvernail) writes: > [...] but the resulting decoded file is larger > than the original and will not run. All the compare utilities I have at > hand die when they see the different sizes, so I don't have a firm idea > of the problem yet... but it strikes me that this may be a DOS/Unix > clash. Print doesn't automatically add a newline, but could it be > expanding any \n it finds in the unpacked $_ to a CR/LF combination? A bit more deductive info.... I found and ran cmp on the decoded file vs. the original. Sure enough, each instance of 0x0a in the original file has been replaced with 0x0d, 0x0a. I also furiously RTFM and found a reference to binmode(HANDLE), but was unable to get it to work. I tried calling binmode both before and after opening the output file, and still got the newline translation. Perhaps binmode works differently in PL41? (I only have man pages for PL18) -- Roy M. Silvernail |+| roy%cybrspc@cs.umn.edu |+| #define opinions ALL_MINE; main(){float x=1;x=x/50;printf("It's only $%.2f, but it's my $%.2f!\n",x,x);} "This is cyberspace." -- Peter da Silva :--: "...and I like it here!" -- me