delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1996/11/03/05:10:39

Date: Sun, 3 Nov 1996 12:08:46 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Daisuke Aoyama <jack AT st DOT rim DOT or DOT jp>
Cc: DJGPP WORKERS <djgpp-workers AT delorie DOT com>
Subject: Re: bash 1.14.7(3) is available
In-Reply-To: <199610072135.GAA16777@mail.st.rim.or.jp>
Message-Id: <Pine.SUN.3.91.961103115034.27986P-100000@is>
Mime-Version: 1.0

On Tue, 8 Oct 1996, Daisuke Aoyama wrote:

> I put new release and diffs on alpha page. See README in
> the archive for dos extentions. You can get it from:

This is *incredibly* good!  I've just finished compiling Ispell 3.1.20
(including the dictionaries build, which uses a lot of shell scripts!),
which I consider to be the Mother of All Tests (as far as using a shell in
a Makefile goes, at least) and it runs like a charm, with almost no
changes to the original Makefiles.  Thank you, Daisuke Aoyama!  I suggest
to consider making a binary package and uploading it to DJGPP archives;
it's stable enough for this IMHO. 

I have only a few minor gripes as a result of this experience:

	* Redirection to /dev/null doesn't work.  I didn't look at the 
bash sources, but I suspect that this is a bug in `stat' (in `_truename', 
to be exact); see my other mail with the necessary libc patches.

	* There is a problem with absolute pathnames like /tmp and /bin/rm. 
Many scripts refer to such like (in the case of /bin/rm, presumably to
avoid any aliases to `rm -i' or something); and TMPDIR which is taken as
the location of /tmp in the ported bash, is in many cases on a RAM disk,
where the available space might be not enough for some heavy shell
scripts.  I suggest to define 2 special environment variables (say,
BASH_BIN and BASH_TMP) that will be used when /bin and /tmp, respectively,
are mentioned.  Actually, for /bin a better way is to just search the
entire PATH, like what `dosexec.c' in the library does when it sees a 
#!/bin/sh in a script.

	* For tests such as [-x gcc] I suggest that if `gcc' is not 
found, bash will look for gcc.exe, or even for the other executable 
extensions (use the `__dosexec_find_on_path' function on `dosexec.c', 
it already knows how to do that).  This will make many scripts which 
search for the executables along the $PATH (the GNU configure script is 
one of them) work unaltered, at least in this aspect.

Once again, thanks a lot!

- Raw text -


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