Problems with TDS and MSDOS Turbo C

Edward Lee edlee at chinet.chi.il.us
Sun Feb 10 10:29:14 AEST 1991


[What follows is a response to a message sent by dionj at netcom.uucp]

I received your message early today, on 9 Feb 1991.  I am currently in 
an out-of-state college, so I have not checked my email often.  You 
write:

 >Mr. Lee, thanks for TDS.
 >[....]
 >When I try tds on my DOS system, to remove carriage returns
 >from an editor file, it fails.  It removes, for example,
 >blanks just fine...but it cannot seem to remove the \h0d
 >characters.  I tried
 >  tds -d \h0d <foo >out
 >  tds -d\r < foo > out
 >
 >and a few other combinations.  Perhaps a bug?
 >If you can fix it, it would be worth $20 to me by return
 >mail.  Email me the code, and send your US mail address. thx.

You do not have to pay me anything for TDS.  It is my way of repaying 
the other program authors who have provided their creations for free 
and the administrators of Usenet who keep the network working.

You are obviously an above-average program user. :-)  I have 
considered using TDS for the (CR/LF -> LF) function you mention.  
Thank you for bringing to my attention the problem with this function 
on a MicroSoft DOS system.

What you are seeing is not a bug of TDS, but rather a bug, or a 
desirable feature, depending on your point of view, of Turbo C's or 
some other MSDOS C compiler's fread() and fwrite() functions.  What is 
happening is that fread() is automatically deleting input Carriage 
Returns, and fwrite() is automatically converting single LineFeeds 
into Carriage Return/LineFeed pairs in its output.  For example, if 
you invoke TDS at an MSDOS prompt in the following way:

     C:> tds <inputfile >outputfile

you then have a fast (*NIX text -> MSDOS text) converter(!).  When you 
do the following at a *NIX shell prompt:

     % tds -d \\r <inputfile >outputfile

what you have is the inverse, a fast (MSDOS text -> *NIX text) 
converter, as you may have originally intended.

If your intent is to convert an MSDOS text file into *NIX format, then 
I suggest that you:

     (1) Try to compile TDS with a different MSDOS C compiler
         such as MicroSoft C (I have already tried Turbo C++ v1.0), or

     (2) Perform (MSDOS -> *NIX text) conversion with TDS on a UNIX
         system:

         a.) Transfer tds.c to the target *NIX system as a binary file.

         b.) Convert tds.c to *NIX format:

              % tr -d \\015 <tds.c >temp;  mv temp tds.c
                ^^
                  Please note the "tr" as opposed to "tds".

         (Or, if your file transfer software is able to perform
         MSDOS to *NIX text conversion on the fly, you can skip steps 
         a & b and just upload tds.c as a text file.)

         c.) Compile tds.c:

              % cc -O -s tds.c -o tds

         Then perform any (MSDOS text -> *NIX text) conversions solely 
         on the *NIX system with TDS.  Or,

         (3) Bring this to the attention of Borland International.  I 
             suspect that fread() and fwrite() are not as ANSI 
             C-compatible as the Turbo C v2.0 and Turbo C++ v1.0 
             reference manuals may lead readers to believe.  
             Representatives are on Usenet, so I will repost this
             letter there.

In investigating this problem, I also discovered that MSDOS v2.11 will 
stop passing any characters down a pipeline except ASCII character 26 
once it sees such a CTRL-Z (^Z or (char)26) character.  While the 
source code for TDS is identical on both *NIX and MSDOS systems, TDS 
is crippled in its ability to correctly handle ASCII characters 13 and 
26 by Turbo C v2.0, Turbo C++ v1.0, and MSDOS v2.11 internals.  Null 
characters are correctly processed, however.



-Ed L



More information about the Comp.lang.c mailing list