Mail Archives: djgpp/2003/03/10/16:30:06
On 10 Mar 2003 20:10:15 GMT, Hans-Bernhard Broeker
<broeker AT physik DOT rwth-aachen DOT de> wrote:
>H Johnson <classy-kg4wou AT kg4wou DOT com> wrote:
>
>> Apparently DOS does care because my clean function does not work...
>
>It's the "del" command that cares, i.e. command.com. COMMAND.COM is
>part of a DOS installation, right. And it's only these external tools
>that really need \ at all. The real core of what DOS is, i.e. the
>Int21h API, accepts / every bit as easily as \.
>
>Anyway: use DJGPP's port of GNU rm (from fileutils) and you'll be
>better off than with 'del', by a mile.
Now that you mention it, I think the problem may be in the
COMMAND.COM. But not just in the "del" command. Other DOS based
programs and apps have the same problem. NASM exhibits the same
problem as does the "del" command. These line in the makefile:
SRC_S = dir1/boot.asm
for %X in ($(SRC_S)) do $(ASM) -M %X >> ./depend.mak
causes havoc with NASM as follows:
nasmw -M dir1
nasmw -M b
nasmw -M oot.asm
So my guess would be that whatever code in COMMAND.COM that the "for"
command executes is not parsing the string properly and passing
whatever program is being called a bogus file name.
While not trying it yet, my guess is that using a DJGPP port of RM
will not fix the problem. If the program being called (whether "del"
or "nasm") is not given the correct file name in the environment
variable then there is nothing any program can do about it.
Sucks....
-H Johnson
- Raw text -