delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/04/26/15:56:39

Date: Wed, 26 Apr 2000 16:11:59 -0400 (EDT)
Message-Id: <200004262011.QAA24188@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: Prashant TR <prashant_tr AT yahoo DOT com>
CC: djgpp-workers AT delorie DOT com
In-reply-to: <200004250158.GAA01227@midpec.com> (message from Prashant TR on
Tue, 25 Apr 2000 06:58:04 +0500)
Subject: Re: Sh-utils 2.0g uploaded
References: <200004250158 DOT GAA01227 AT midpec DOT com>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

> Date: Tue, 25 Apr 2000 06:58:04 +0500
> From: Prashant TR <prashant_tr AT yahoo DOT com>

This is a longish message, sorry.

> The DJGPP port of the Sh-utils pretest is available on v2gnu/beta on Simtel.

Thanks for working on this.

I downloaded and built the package.  Some comments/gripes/questions I
have are listed below.

> 1> I've enabled NLS support during compilation. Is it necessary that I
>    have the .mo files in the binary distribution?

I don't think it makes any sense to build a package with NLS support,
unless you supply the *.gmo files in the binary distribution.

But for that to work with DJGPP, you need to decide (or we need to
discuss here and make up our mind) what DOS codepage to use for
recoding each of the *.po files.  Otherwise, you will risk producing
*.gmo files that would be unusable.

> Any comments on this?

Plenty ;-)

 1) The packaging has some minor problems:

    - There's no need to put the various *.texi files into the info/
      subdirectory in shl20gb.zip.  They don't belong to a binary
      distribution.

    - The man pages in the binary distro are unformatted.  This would
      require users to install Groff to read them.  I'd recommend to
      format them (and put them into man/cat1 instead of man/man1).

    - Why are the files fnchange.* and README.in in the binary distro?

    - It is best not to include top-level directories such as bin/,
      gnu/, lib/, and manifest/ in the distribution and in the *.mft
      files.  Someone might say "rm -rf @shl20gb.mft" and accidentally
      nuke their entire DJGPP tree!

    - It's probably a good idea to add DSM files to the distribution.

    - Are the binaries stripped?  They seem too large.

    - The *d.zip distribution, if you want to prepare one, should
      include the DVI and PostScript versions of the docs.

 2) The source distribution configures and builds okay on Windows 98
    and on DOS, except for the following problems:

    - It would be better if users were not required to run the
      configure script if they don't need to.  Is it possible to
      distribute a configured package?  If not, why not?

    - When configuring on DOS, the configure script complains:

      d:/foo/gnu/sh-util2.0g/conftest.sym.exe: No such file or directory

      This happens when it checks whether lstat derefrences a symlink
      specified with a trailing slash.  The problem is, of course,
      that "ln -s" tries to create conftest.sym.exe which is an
      invalid name on DOS.

      However, the upshot is that the test fails, as it should, so I'm
      not sure you need to bother about this (especially since the
      solution is messy ;-).

    - Configuring from another directory fails if the source directory
      is given with a drive letter, like this:

       d:\foo\gnu\sh-util2.0g\djgpp\config d:/foo/gnu/sh-util2.0g

      The error message printed by ./configure is this:

       creating Makefile
       configure: error: cannot find input file `e'

      (E: is the drive letter where I ran this.)

      As far as I could see, this happened because the $@#&*! Autoconf
      have changed the produced script so that the following fragment
      of the config.sed script no longer does its magic:

       # Switch the order of the two Sed commands, since DOS path names
       # could include a colon
       /ac_file_inputs=/s,\( -e "s%\^%\$ac_given_srcdir/%"\)\( -e "s%:% $ac_given_srcdir/%g"\),\2\1,

      I suggest to leave this snippet alone, but add another one which
      does work with the changed configure script.  (To find how the
      offending line looks today, search the configure script for the
      string "ac_file_inputs".)

    - When building the package, GCC complains like this:

       gcc -DLIBDIR=\"c:/bin/gcc/lib\" -DHAVE_CONFIG_H -I.. -I. -I../intl    -g -O2 -c -o makepath.o makepath.c
       makepath.c:114: warning: redefinition of `uid_t'
       c:/bin/gcc/include/sys/types.h:37: warning: `uid_t' previously declared here
       makepath.c:115: warning: redefinition of `gid_t'
       c:/bin/gcc/include/sys/types.h:22: warning: `gid_t' previously declared here

      This is due to this snippet from makepath.c:

      #ifdef __MSDOS__
      typedef int uid_t;
      typedef int gid_t;
      #endif

      makepath.c is not used in Sh-utils, but warnings aren't nice,
      IMHO.  I have makepath.c from Fileutils 3.16, where it says
      thusly:

      #if defined(__MSDOS__) && !defined(HAVE_CONFIG_H)
      typedef int uid_t;
      typedef int gid_t;
      #endif

      Which does The Right Thing, since the configure script already
      tests for the correct declaration of uid_t and gid_t.  I'm
      guessing that this is a relic from some ancient DOS port.

 3) "make check" fails for me in several ways:

    - It complains about "/bin/sh" and (if I arrange for /bin/sh to
      exist) about Perl, although I definitely have Perl installed.

      As far as I could see, the reason is that several Makefile's in
      the test suite (and elsewhere) use a colon as a PATH separator.
      There's a fragment in djgpp/config.sed that is supposed to take
      care of this, but it somehow isn't working.  I didn't have time
      to look closer at this, so I simply replaced : with ";" manually
      in those Makefile's.  Then the test suite started running, but
      some of tests failed, as described below.

    - The tests which test failure messages don't pass because DJGPP
      programs have their full path in argv[0], while the test suite
      expects a relative path.  Thus, the test suite expects to see,
      e.g., "basename: too many arguments", but our port prints
      "d:\foo\bar\basename.exe: too many arguments".  The tests which
      fail like that are basename/basic and factor/basic.

    - The tests for the `date' utility all fail.  I think this is
      because all the *.X files have Unix-style end-of-line format,
      while the corresponding *.O files are generated with DOS-style
      CRLF end-of-line format, and the test suite uses `cmp' to
      compare them.

      The solution is either to use `diff' for comparison or to run
      `utod' on *.X files inside edtests.bat.

    - The stty tests fail because they try to use a file named
      `.saved-state' which is invalid on DOS.

    - The last test, for `nice' either wedges my machine or reboots
      it.  The problem is that the test tries to run the command
      "nice nice", but there's a shell script called `nice' in
      the same directory, and our `execvp' looks in the current
      directory first...

      I solved this by replacing "nice" with "nice.exe" in the test
      script tests/nice.

      After this, the test for `nice' simply fails because we don't
      inherit the nicety level to child programs.  (If we do want to
      inherit it, we will have to export an environment variable and
      modify `nice' in the library to pay attention to that variable.)

    I wonder if the test suite worked for you, and if so, how.

 4) The following fragment you added to djgpp/config.bat should IMHO
    be rethought:

      Rem workaround for bug in ported BASH.
      cp -f %XSRC%/lib/Makefile %XSRC%/lib/Makefile.orig1
      sed -e "s|\`test -f .*\`||g" %XSRC%/lib/Makefile.orig1 > %XSRC%\lib\Makefile
      cp -f %XSRC%/src/Makefile %XSRC%/src/Makefile.orig1
      sed -e "s|\`test -f .*\`||g" %XSRC%/src/Makefile.orig1 > %XSRC%\src\Makefile

    The problem with this is that it replaces files in the source
    directory.  This will fail if the source directory is on a CD-ROM.
    If possible, it is better to find a solution that copies the files
    into the working directory and modifies them there.

 5) Why is the file djgpp/finish.sh needed?  (Yes, I see the part of
    djgpp/README that mentions it, but I still don't get it.  Perhaps
    I don't understand why charset.alias is required.)

 6) The test suite requires Perl and Awk.  I suggest to mention this
    in djgpp/README.

 7) What is the file djgpp/renfiles.bat for?

 8) It's probably a good idea to mention any DOS-specific issues in
    sh-utils.texi.  For example, several programs print an error
    message because the underlying functionality doesn't exist; this
    should be in the docs, IMHO.  (Btw, pinky doesn't seem to be
    documented there?)

 9) Some of the changes I did when porting Sh-utils 1.12 didn't make
    it into this port.  Is there any reason for not including them?

    Here's a list of my changes I didn't find in your port (you can
    see them all in the file DIFFS in shl112s.zip):

     - the addition of DOS shells to default_shells[], and the special
       environment variable for the location of /etc/shells in
       lib/getusers.c

     - support for drive letters in lib/stripslash.c

     - binary I/O mode from/to pipes/files in tee.c

     - additional check for FOO.exe if FOO is not found in test.c,
       when the -x switch is given

     - su.c omits quite a few of my old changes; does that mean any
       change in functionality, or did you find an easier way of
       achieving the same goal?

10) As a general comment about your changes: DJGPP-specific changes
    should be conditioned on __DJGPP__, not __MSDOS__.  One example is
    use of __dosexec_find_on_path in su.c.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019