Date: Wed, 26 Apr 2000 16:11:59 -0400 (EDT) Message-Id: <200004262011.QAA24188@indy.delorie.com> From: Eli Zaretskii To: Prashant TR 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 Precedence: bulk > Date: Tue, 25 Apr 2000 06:58:04 +0500 > From: Prashant TR 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.