Mail Archives: djgpp-workers/2001/01/07/04:57:14
> > 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
I wasn't suggesting you made those changes, just that my mail
was sent because I noticed the change to wc204.txi you made.
> 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?).
Actually, yes I did. Even looks just like Unix (I use it for a
simple batch file to run make in a large tree and create a file
with its log. I was surprised to see 'make -k >foo.log 2>&1' work,
but it does.)
> > 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?
What I mean is that I now have 'automake.pl', not 'automake' and
'autoconf.sh', not 'autoconf', in $DJDIR/bin. As I understood it,
when a DJGPP program now tries to run 'autoconf', it will no longer
run 'autoconf.sh'.
I took a look at src/libc/dos/process/dosexec and it would seem there
is no such problem after all; .sh and friends simply aren't tried BEFORE
an extensionless file. They're still tried though (and Eli, you might want
to amend that entry in wc204.txi, as it's __spawnve, and not
__dosexc_find_on_path that skips interpreted extensions). Only bash 2.04
seems to leave them out entirely (and even that's only in as far as I
recall).
> 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.
True enough. It should be easy enough to scan the environment and
insert them into 'interpreters' (although it'll have to become an array
instead of an array). I'll see what I can do.
> 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.
I suppose so. Of course, I didn't have full-time Internet access at that
time (I think), and I only remembered when seeing the entry in wc204.txi.
- Raw text -