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

From: "Mark E." <snowball3 AT bigfoot DOT com>
To: djgpp-workers AT delorie DOT com
Date: Mon, 3 Apr 2000 14:47:33 -0400
MIME-Version: 1.0
Subject: Re: Bash 2.04 beta 1 now available
Message-ID: <38E8AF05.4358.10FAD1E@localhost>
References: <38E71B1E DOT 17249 DOT B912B AT localhost>
In-reply-to: <Pine.SUN.3.91.1000403104804.26246D-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp-workers AT delorie DOT com

> Is that really a good idea?  This could break non-DJGPP programs

Why use DJGPP-specific filenames with non-DJGPP programs?

> 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.
> 
> What are the reasons for dropping PATH_EXPAND, anyway?  After all, if 
> someone doesn't want it, they can simply avoid using it.

Because updating the SimTel packages will fix the need for this, and 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. 
Chances are slim and none that this feature will be put back as-is. I am open 
to another way of handling this translation, as long as it's easier to 
maintain. 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`' 


> And what about PATH_SLASH?  

It decides which directory separator is used for environment variables that 
are converted from 'c:/foo/bar' to '/dev/c/foo/bar' form. When PATH_SLASH is 
'\', PATH_SEPARATOR is ':', and PATH is 'c:\djgpp\bin;c:\windows', PATH in 
Bash is translated to '\dev\c\foo\bar'. The problem with this is Bash doesn't 
recognize '\' as a path separator, and libc's _put_path2 won't translate it 
properly. Slashes are always translated to backslashes in the exported 
environment, so PATH_SLASH serves no purpose there either.

> 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? If so, I agree it wasn't a 
very good solution.


- Raw text -


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