Mail Archives: djgpp-workers/2000/04/03/15:16:26
> 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 -