[comp.binaries.ibm.pc.d] Decoded files are double spaced using UUDECODE?

ain149e1@merrimack.edu (03/17/90)

Hello out there.

Maybe someone out there in net land can solve this one for me.  I've been
having trouble with taking files off the VAX at school and putting them on the
IBM at home.  I think I have found the problem, the question is how do I solve
it?

The problem starts easily enough.  The files I brought home, I UUDECODED, and
they didn't run.  I unzooed or unziped as necessary, and they still didn't run. 
Then I decided that to be sure, I would encode a program of mine and then
decode it to see if they came out the same.  So I took some Pascal source code
and UUENCODED it.  Then I UUDECODED it, and I got the source code back, but low
and behold, the thing was double spaced!  It wasn't when I encoded it, but I
was after decoding.  So to test it furthur, I took a letter I had written in
PFS First Choice, and printed the contents to a disk to create a text file on
the disk.  I UUENCODED this and then UUDECODED it.  Guess what, same thing.

So I know that the problem is on my end.  Now it's a question of whether it is
the encoding is screwing up causing the decoding to be screwed up or whether
the decoding is just screwing up.

Anyone have any thoughts?

Kevin

P.S. The source code is in C.  I have it if you are interested, let me know.

georgf@polari.UUCP (George Forsman) (03/18/90)

In article <18822.26015aaa@merrimack.edu> ain149e1@merrimack.edu writes:
>Hello out there.
>
> [discussion of how files become double-spaced after a uuencode/uudecode
>  cycle]
>
>Anyone have any thoughts?
>
>Kevin
>
>P.S. The source code is in C.  I have it if you are interested, let me know.

Since you mention the source, I assume that you are compiling it yourself,
and not using a "canned" executable.  My guess is that an fopen() is lurking
in there that opens the file in TEXT (cooked) mode, rather than BINARY (raw)
mode.  This will cause a translation of CR characters (0x0d) to a CR/LF pair
(0x0d/0x0a).  Since text files on an IBM already have a CR/LF pair, the
cooked file write will translate the CR into CR/LF, then proceed to write
the LF from the original CR/LF pair.

     -George

This is, of course, only a best guess at the problem.
----
uucp: ...uw-beaver!sumax!polari!georgf