From: "Tim Van Holder" To: Cc: Subject: Re: .sh etc. as executable extensions Date: Sun, 7 Jan 2001 10:58:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id EAA11286 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 Precedence: bulk > > 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.