Mail Archives: djgpp-workers/1999/03/28/07:24:53
On Fri, 26 Mar 1999, Michel de Ruiter wrote:
> If a user named his program (sh-script or
> COFF binary) `foo.bar.bat', he should expect problems anyhow. I think
> COMMAND.COM will also interpret the filename to be a batch file.
I don't think we need to limit the functionality of libc functions
based on what COMMAND.COM does. We don't call COMMAND.COM *precisely*
because it is too dumb.
> In this case, if someone typed `foo.bar.bat' in Bash,
> `foo.bar.bat.exe' should be tried first IMHO, then `foo.bar.bat', then
> `foo.bar.bat.bat' etc.
That's exactly what happens if you call `foo.bar.bat'. But in your
case, you called `foo', and I was talking about the case where you
call `foo.bar'.
> I do not have an opinion about whether to treat
> `foo.bar.bat' as a batch file or not in this case...
The libc functions check whether the file is a COFF-, shell-script- or
.exe-style executable before falling back to the possibility it's a
batch file, even if the file's extension is `.bat'.
> > Moreover, there could be a directory `foo' and a program `foo.exe', in
> > which case again it is better to try `foo.exe' first.
>
> Or, a directory called `foo.exe' might exist and a program named
> `foo'. I agree it will be rare but so are files called
> `foo.bar.bat.exe' :-)
The rare case with a directory called `foo.exe' and the file `foo'
doesn't cause a failure, `spawn' does check whether the file is a
directory and if it is, it keeps trying other alternatives. The issue
here is to test the frequent case before the infrequent one.
> Also, IIRC some versions of Binutils are able to generate go32-exes
> immediately (no raw COFF), removing the go32-v2 problem. What
> drawbacks exist to making this behaviour the default? Robert?
It breaks some clever logic inside the ported GNU `install', for
starters. Another problem is that COMMAND.COM won't run such programs
from the command prompt.
- Raw text -