Date: Sun, 7 Jan 2001 09:41:31 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder cc: DJGPP Workers Mailing List Subject: Re: .sh etc. as executable extensions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.