Date: Sun, 16 Oct 94 21:44:50 JST
From: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Definitive GNU fileutils ports 

EZ wrote:

   >  I'm not real sure just what the Backus ports are, but I've FTP'd
   > the orig.  fileutils and such from the Free Software Foundation,
   > and they seemed to compile OK, with a few changes and a
   > hand-tweaked makefile. Does anybody have suggestions as to where
   > to FTP them to once I've put together the 'Diff' files and watt
   > knot?

I was composing a "please, DON'T" reply but Eli puts it better than I
could:

   Beware of such simple-minded ports.  While most GNU (and otherwise Unix)
   programs would compile without a single warning in DJGPP, they will refuse
   to run under DOS in best case and will have subtle bugs in the worst.
   Some reasons are:

	   1) library functions which intentionally fail at run time (like
   signal(), fork() and others).

However, for people running in the DESQview/X (*not* DESQview)
environment, some good, nearly compatible substitutes are provided,
eg, using file descriptors for sockets.  Of course, simply forgetting
signals often results in workable programs in a brain-damaged
environment like DOS.

	   2) file I/O is different with text and binary files (try compiling
   cp, then use it to copy a binary file, like .exe).

I have long agreed with Marty Leisner's position that making binary,
not text, the default in file I/O, is the nearly perfect solution to
this *for personal use*.  For historical reasons I hesitate to suggest
this for the DJGPP package as a whole, and of course for wide
distribution of general-purpose utilities like cp, rm, and so on this
is just not robust enough.
    Marty and I use mostly Unix-derived tools, often ported with
DJGPP, on our DOS systems, and again we read them on our Linux
systems.  So binary copy conventions are fine.  But for people who
heavily use DOS tools, you have to get this right in the defaults, and
you should provide dos2unix and unix2dos options (since piping is not
transparent in DOS).  Not even the Backus ports do this, though---it's
just on my wish list.  Of course I assume that console utilities like
`cat', `echo', and `cp >con:' have to get this right.  (I wouldn't
know, essentially all my console output gets piped through 4DOS's
`list' :)

	   3) DOS limitations and peculiarities, like 8.3 filenames, drive
   letter as part of filename, etc.

A lot of this gets handled by DJGPP, either in the library or GO32, it
seems to me.  Again, however, you can't just cavalierly ignore it in a
tool intended for wide distribution.
    However, I have gotten rather good mileage out of tools like grep
and gawk that I have compiled myself.  A key there is that these
come with a package of regression tests.  (Not terribly complete
in either case, but still.)  I would suggest that any person who ports
the fileutils and textutils make up such test with specific attention
to binary/text file distinctions (CRLF and SUB = EOF conventions),
bombing on illegal filenames, drive letters and the like, handling of
pipes as filenames, I/O redirection, use as a child, etc.

    --Steve