Mail Archives: djgpp-workers/2001/01/07/02:43:12
On Sun, 7 Jan 2001, Tim Van Holder wrote:
> I noticed the change to wc204.txi made by Eli, explaining why
> .sh and friends were no longer being searched for in
> __dosexec_find_on_path.
To make it clear: that was just a "What's changed" entry; the real change
was done long ago by Mark. I just noticed that the change is not
mentioned in wc204.txi, which forced me to search mail-archives for the
reasons (which I forgot) when someone asked about that on c.o.m.d. So I
thought it would be a good idea to have the change and its reasons
explained in wc204.txi.
> A similar situtation exists on Windows (might be just NT), where
> extensions can be made "runnable" from the command line (the
> ActiveState distribution does this for perl).
Yes, it's an NT-only feature. Actually, it's a feature of CMD.EXE,
together with a few more relatively unknown and unused features (did
you know that CMD.EXE supports stderr redirection?).
> Now, because of the change to the DJGPP library, those will no
> longer be available (unless I also keep an extensions-less
> version in the path, which is a maintenance nightmare).
I don't understand why. DJGPP doesn't change how your shell works, so
how can it break anything?
In any case, it should be clear to you that if you define in 4DOS any
extensions except .sh, .ksh, .pl, and .sed, it won't work in the old
library as well; it's just a coincidence that the current extensions are
good for you. If we want this feature supported in the library, we
might as well support it consistently.
> I could always build my own libc with those extensions
> re-enabled (as I did with bash 2.04, which included a similar
> change)
It would be better if you raised this issue right when you saw it in
Bash 2.04, instead of waiting for its explanation in wc204.txi.
- Raw text -