Mail Archives: djgpp/1997/05/04/14:41:49
This is to announce that the DJGPP port of GNU Fileutils 3.16 has been
uploaded to SimTel.NET mirrors:
ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/fil316b.zip
ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/v2gnu/fil316s.zip
Fileutils include programs that operate on files: list them, copy, them,
move them, remove (delete) them, etc.
Please read the files README and NEWS (included in the binary
distribution as well), for general and DJGPP-specific enhancements and
bugfixes in this version. The DJGPP-specific README file is attached
below.
-------------------------------------------------------------------------
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 AT verity DOT ICS DOT UCI DOT 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 DOT oberhumer AT jk DOT uni-linz DOT ac DOT 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.
Then issue these two 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 AT is DOT elta DOT co DOT il>
- Raw text -