Date:	Tue, 4 Apr 2000 13:55:01 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Mark E." <snowball3 AT bigfoot DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Bash 2.04 beta 1 now available
In-Reply-To:	<38E8AF05.4358.10FAD1E@localhost>
Message-ID:	<Pine.SUN.3.91.1000404135413.9459E-100000@is>
MIME-Version:	1.0
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

On Mon, 3 Apr 2000, Mark E. wrote:

> > Is that really a good idea?  This could break non-DJGPP programs
> 
> Why use DJGPP-specific filenames with non-DJGPP programs?

Because some shell script might require that.  The /dev/c/foo feature
was invented to help out shell scripts which would be impractical to
modify.

Also, there are people who use Bash as their interactive shell, which
means they invoke non-DJGPP programs from it.  If they set
PATH_SEPARATOR=: (for running shell scripts), the non-DJGPP programs
will break.

> > and > DJGPP programs compiled with old versions of libc.
> 
> Then update them. The only package left that needs PATH_EXPAND for use in 
> configure scripts is Fileutils.

So this means people won't be able to upgrade to the new Bash until I
find the time to report Fileutils (and Sh-utils, and Findutils, and
cpio, and TeX/Web2c, and...)?  Sounds a bit too tough on users,
doesn't it?

> the code 
> to implement it is very fragile and has become unmaintainable and unreliable 
> due to internal changes starting in Bash 2.03 and more so in Bash 2.04. 

FWIW, I didn't have any problems in Bash 2.03 with these features.

> I am open 
> to another way of handling this translation, as long as it's easier to 
> maintain.

I have never looked at the sources that do this conversion.  If you
could explain why is it hard to maintain, perhaps someone could come
up with useful ideas.

> The only idea I to offer (and it's a bad one) is to create a 
> builtin called 'realpath', so 'realpath /dev/c/djgpp/bin' would write 
> 'c:/djgpp/bin' to stdout. Then do 'prog.exe `realpath /dev/c/djgpp/bin`' 

This would mean that shell scripts will have to be changed, which
kinda defeats the purpose of the feature.

> Slashes are always translated to backslashes in the exported 
> environment, so PATH_SLASH serves no purpose there either.

Yes, I agree.  I wonder if PATH_SLASH was ever widely used at all; I
don't think I recall anybody ever asking about it.

> > As for SYSROOT, I have no problems with dropping it: I think it was evil in
> > the first place.
> 
> Was it supposed to handle the '/bin/sh' problem?

Not /bin/sh (which was supported by the library since v2.01), but
other /bin/foo and /tmp strings you meet in many shell scripts.  These
cases are nowadays considered bugs by all GNU maintainers, so the
right solution is to fix the scripts instead of using SYSROOT.

- Raw text -