This is a port of GNU Fileutils 3.16 to MSDOS/DJGPP.


Features
========

This port has the following DOS-specific features:

  1) All the programs fully support long filenames.  For instance, on
     Windows 95 you get numbered backup file names as you'd see on
     Unix; `touch' can change both access and modification times,
     etc.

  2) Numbered backups work even on native MSDOS, although the numbered
     suffix eats last characters of the filenames on FAT filesystems.

  3) `chgrp' and `chown' are no-ops on MSDOS; however, they always
     return a successful status and describe the change as if it were
     actually happening.  This allows Unix-born Makefiles to run
     unaltered.

  4) `chmod' also behaves as above if invoked to do anything except
     making a file read-only (which is actually supported by MSDOS).
     Since the execute and other bits only exist in the program's
     imagination, they don't really change, although `chmod' acts as
     if they did.

  5) `ls', `dir' and `vdir' support the new color printing feature.
     You don't need to install ANSI.SYS to get the colorization of the
     filenames according to type.  If you want to customize the
     colors, define the `LS_COLORS' environment variable; the setting
     on DJGPP.ENV should supply a starting point.
     A DOS-specific -g switch makes the long format print MSDOS
     attribute bits (r,h,s,v,d,m) instead of the Unix-style mode bits.
     When called with -a switch, `ls' will display files with hidden
     and system attributes, and volume labels (if present).

  6) `ginstall' will stubify a COFF executable on the fly.  When given
     the -s option, `ginstall' will strip the executable, either COFF
     or .exe program (you will need `strip' from Binutils 2.7 or later
     to be able to strip .exe programs).

  7) `ln -s' supports DJGPP-style executable ``symlinks'': you can
     say "ln -s grep fgrep" and get `fgrep.exe' which, when run, will
     actually call `grep.exe'.  `ln' without -s just copies.

  8) `sync' attempts to cause the disk cache, if installed, to flush
     its buffers.

The file DIFFS in the top installation directory describes the changes
against the original package.


Enhancements and bugfixes
=========================

See the file NEWS for a list of changes that aren't specific to
MS-DOS/DJGPP.  If you are familiar with the previous DJGPP port of
Fileutils 3.13, here's the list of DJGPP-specific enhancements in this
port:

  1) `df' now reports the true size of CD-ROM disks instead of the
     standard (and incorrect) 131MB returned by MSCDEX.  It does so by
     using CD-specific calls, and will fall back to the old method
     when the CD-specific calls fail, so some non-standard CD drivers
     might still cause it to return 131MB.  If you encounter such
     cases, please report them.

  2) `df' will no longer print an error message when a drive for
     removable media (such as JAZ) is empty.  It will skip and not
     report such drives unless the media is in place.

     Many thanks to Dan Hirschberg <dan@verity.ICS.UCI.EDU> for
     helping to debug the above two problems on an NT box.

  3) Previously, `df' was reading the VTOC (Volume Table Of Contents)
     of the CD to check whether there was a disk in the drive.  Due to
     the peculiarities of the CD-ROM driver operation when a new disk
     is insered, this would trick MSCDEX into thinking that the disk
     wasn't changed and return stale directory/file information to DOS
     calls.  That could cause subsequent programs to crash, or even
     wedge the entire system in some cases.  This problem is now
     fixed.

  4) The backup file creation when numbered backup is used and a
     backup with a .~9~ extension already exists, now works correctly
     by creating a file without an extension which ends with "10~".
     (In the previous port, a file with a .~10 extension would be
     created instead.)

  5) `ginstall' will no longer overwrite existing stubified .exe
     programs when its first argument is raw COFF executable.
     Prevously, when called like this:

		     ginstall foo c:/bin

     and if `foo' was a raw COFF executable, `ginstall' would generate
     stubified DOS-style `foo.exe' program even if `foo.exe' already
     existed in the same directory as `foo'.  This was wrong when
     `foo.exe' has been stub-edited, because the new `foo.exe' would
     have the fresh, unedited stub.  The new version of `ginstall'
     will only create `foo.exe' if it doesn't already exist; if it
     does exist, `ginstall' will copy `foo.exe' without changing it.

  6) A bug was corrected in `mv' whereby "mv -v foo b:" would print
     "foo -> b://foo" (with two slashes instead of one).

  7) `rm' will now correctly remove directories with files whose
     hidden or system attribute bits are set.  Previously, it would
     fail to remove such directories.  (Thanks to Oberhumer Markus
     <markus.oberhumer@jk.uni-linz.ac.at> for correcting this.)


Known bugs
==========

  1) `df' crashes when your DPMI host is QDPMI and the disk inside the
     CD-ROM drive is an audio (as opposed to data) disk.  `df' might
     also show incorrect info, or print an error message, or even
     crash (under QDPMI) if you invoke it while the CD drive is
     accessing the disk immediately after you change the CD and close
     the tray.  To avoid these side-effects, only invoke `df' when the
     CD is a data disk, and only after the drive has finished its
     initial disk access (the "BUSY" LED is off).

     Note that empty CD drives and data disks should not fail or crash
     `df', no matter which DPMI host do you use.  Audio disk that is
     being played at the time of `df' invocation will not be reported,
     and should not crash `df'.

  2) `df' returns incorrect disk usage info for NTFS partitions, when
     run from the Windows/NT DOS box.  This is due to a bug in the NT
     emulation of DOS function 36h.  If anybody knows how to work
     around this bug, please tell me.


Installation of the binary package
==================================

Unzip the distribution preserving the directory structure (use -d
switch if you do that with PKUNZIP) from the top DJGPP installation
directory.  Since the entries for Fileutils manual already exist in
the file info/dir, you don't need to do anything else.



Tools required to rebuild the package
=====================================

If you want to recompile the package, you will need the following
tools:

	- GNU Make 3.75 or later
	- GNU Bash
	- GNU Sed
	- GNU Fileutils (a port of 3.13 is good enough)
	- GNU Textutils
	- GNU Sh-utils
	- GNU Grep
	- GNU Bison (only if you change one of the *.y files in lib
	      subdirectory)

These should be available from the DJGPP sites.  There are a few more
programs (such as `update') invoked during the build process, but they
are all part of a standard DJGPP installation and should be already
installed on your system.

If you change the `dircolors.hin' file in the `src' subdirectory, you
will need Perl to recreate `dircolors.h'.

Most of the enhancements listed above are due to changes in library
functions.  The sources of the fixed functions can be found in the
djgpp subdirectory.  You should compile them and put them into your
libc.a before rebuilding the package from sources, like so:

	      gcc -O3 -c xyzzy.c
	      ar rvs c:/djgpp/lib/libc.a xyzzy.o

(Replace `xyzzy' with the name of each source file, and `c:/djgpp'
with the actual pathname of the top DJGPP installation directory on
your machine.)


How to build
============

Unzip the distribution preserving the directory structure (use -d
switch if you do that with PKUNZIP).  On Windows 9x, be sure to use an
unzip program that supports long filenames, or set LFN=n before you
run Make.

This package has been configured. To build the binaries issue
the command:
		make

If for same reason you need to reconfigure the package
before you build the binaries you will have to run the commands:
		djgpp\config
		make

That's all!

The build process creates several `symlinks' such as `gdir.exe' and
`gmkdir.exe', so that you can invoke `dir', `mkdir' etc., which are
internal DOS commands, from the DOS COMMAND prompt.  (Alternatively,
you could define an alias, if your environment supports them.)  But
leave the original programs (`dir.exe', `mkdir.exe' etc.) on your
PATH, since Make and other DJGPP programs look on the PATH before
considering internal shell commands.

The GNU Gettext package is not supported yet in the ported version, so
don't expect the programs to talk to you in any language but English.


		Enjoy,
				Eli Zaretskii <eliz@is.elta.co.il>
