The Windows version of rdmd passes incorrect command line arguments to the program to be run. Here's a test program:

  import std.stdio;

  int main(char[][] args) {
    writefln("ARGS: ", args.length, " ", args);
    return 0;
  }

Here's a correct run with dmd (the program gets the correct args):

$ dmd -run ./printargs.d AA BB CC
ARGS: 4 [d:\#scripts\printargs.exe,AA,BB,CC]

Here's what happens when you run the same program with rdmd:

$ rdmd -run ./printargs.d AA BB CC
ARGS: 3 [d:\#scripts\printargs.exe,-ofc:/Home/phoenix/LOCALS~1/Temp\-phoenix-0-0
-523934D89A617F8383F6035B5D2CC826.exe,-odc:/Home/phoenix/LOCALS~1/Temp\]

The Linux version of rdmd seems to run fine (I haven't tested myself, I asked someone else on #D)


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

In article <e5c3t9$2vvq$1@digitaldaemon.com>, Bruno Medeiros says...
>
>The Windows version of rdmd passes incorrect command line arguments to the program to be run. Here's a test program:
>
>   import std.stdio;
>
>   int main(char[][] args) {
>     writefln("ARGS: ", args.length, " ", args);
>     return 0;
>   }
>
>Here's a correct run with dmd (the program gets the correct args):
>
>$ dmd -run ./printargs.d AA BB CC
>ARGS: 4 [d:\#scripts\printargs.exe,AA,BB,CC]
>
>Here's what happens when you run the same program with rdmd:
>
>$ rdmd -run ./printargs.d AA BB CC
>ARGS: 3
>[d:\#scripts\printargs.exe,-ofc:/Home/phoenix/LOCALS~1/Temp\-phoenix-0-0
>-523934D89A617F8383F6035B5D2CC826.exe,-odc:/Home/phoenix/LOCALS~1/Temp\]
>
>The Linux version of rdmd seems to run fine (I haven't tested myself, I asked someone else on #D)
>

rdmd doesn't need '-run'. If I run it with the above code, I get this on linux:

ARGS: 4 [/tmp/rd-0-834-509947-D7B8821E97DC98D3C34D2F29E2EE2115,AA,BB,CC]

and this on Windows:

ARGS: 4 [C:\DOCUME~1\SOMEUS~1\LOCALS~1\Temp\rd-someuser-0-0-A46C236CDE107E3B9F053881E4257C2D.exe,AA,BB,CC]

(the line-break was inserted by the news reader)

args[0] is the actual path to the 'cached' executable.

Dave wrote:
> In article <e5c3t9$2vvq$1@digitaldaemon.com>, Bruno Medeiros says...
>> The Windows version of rdmd passes incorrect command line arguments to the program to be run. Here's a test program:
>>
>>   import std.stdio;
>>
>>   int main(char[][] args) {
>>     writefln("ARGS: ", args.length, " ", args);
>>     return 0;
>>   }
>>
>> Here's a correct run with dmd (the program gets the correct args):
>>
>> $ dmd -run ./printargs.d AA BB CC
>> ARGS: 4 [d:\#scripts\printargs.exe,AA,BB,CC]
>>
>> Here's what happens when you run the same program with rdmd:
>>
>> $ rdmd -run ./printargs.d AA BB CC
>> ARGS: 3 [d:\#scripts\printargs.exe,-ofc:/Home/phoenix/LOCALS~1/Temp\-phoenix-0-0
>> -523934D89A617F8383F6035B5D2CC826.exe,-odc:/Home/phoenix/LOCALS~1/Temp\]
>>
>> The Linux version of rdmd seems to run fine (I haven't tested myself, I asked someone else on #D)
>>
> 
> rdmd doesn't need '-run'. If I run it with the above code, I get this on linux:
> 
> ARGS: 4 [/tmp/rd-0-834-509947-D7B8821E97DC98D3C34D2F29E2EE2115,AA,BB,CC]
> 
> and this on Windows:
> 
> ARGS: 4
> [C:\DOCUME~1\SOMEUS~1\LOCALS~1\Temp\rd-someuser-0-0-A46C236CDE107E3B9F053881E4257C2D.exe,AA,BB,CC]
> 
> (the line-break was inserted by the news reader)
> 
> args[0] is the actual path to the 'cached' executable.
> 
> 

Hum, I found it does work after all, but only when called from the Windows Command prompt! If I call it from a MinGW shell I get an error (which was what originally made think one wasn't supposed to use -run). Substituting dmd for the very printargs.exe, here's what is found:

When one runs rdmd from the Win CMD shell:

> rdmd dummy.d
ARGS: 5 [C:\devel\D.tools\dmd\bin\dmd.exe,-quiet,dummy.d,-ofc:\Home\phoenix\
LOCALS~1\Temp\dummy-phoenix-0-0-A46C236CDE107E3B9F053881E4257C2D.exe,-odc:\H
ome\phoenix\LOCALS~1\Temp\]

(DMD would run fine)
But when one runs rdmd from the MinGW bash shell:

$ rdmd dummy.d
ARGS: 5 [c:\devel\D.tools\dmd\bin\dmd.exe,-quiet,dummy.d,-ofc:/Home/phoenix/
LOCALS~1/Temp\dummy-phoenix-0-0-A46C236CDE107E3B9F053881E4257C2D.exe,-odc:/H
ome/phoenix/LOCALS~1/Temp\]

Some of the slashes are inverted, and that makes OPTLINK choke. Weird. How does rdmd have this different behaviour, I mean, how does it even know it's running under a different shell/environ/whatever? :/


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Hum, I found it does work after all, but only when called from the Windows Command prompt! If I call it from a MinGW shell I get an error (which was what originally made think one wasn't supposed to use -run). Substituting dmd for the very printargs.exe, here's what is found:
> 
> When one runs rdmd from the Win CMD shell:
> 
>  > rdmd dummy.d
> ARGS: 5 [C:\devel\D.tools\dmd\bin\dmd.exe,-quiet,dummy.d,-ofc:\Home\phoenix\
> LOCALS~1\Temp\dummy-phoenix-0-0-A46C236CDE107E3B9F053881E4257C2D.exe,-odc:\H 
> 
> ome\phoenix\LOCALS~1\Temp\]
> 
> (DMD would run fine)
> But when one runs rdmd from the MinGW bash shell:
> 
> $ rdmd dummy.d
> ARGS: 5 [c:\devel\D.tools\dmd\bin\dmd.exe,-quiet,dummy.d,-ofc:/Home/phoenix/
> LOCALS~1/Temp\dummy-phoenix-0-0-A46C236CDE107E3B9F053881E4257C2D.exe,-odc:/H 
> 
> ome/phoenix/LOCALS~1/Temp\]
> 
> Some of the slashes are inverted, and that makes OPTLINK choke. Weird. How does rdmd have this different behaviour, I mean, how does it even know it's running under a different shell/environ/whatever? :/

It doesn't know. The mingw shell is buggy. It doesn't follow Windows conventions, and so screws up programs that do. I've gotten numerous mysterious bug reports over the years that eventually got traced back to the mingw shell. Stop using it, and the problems disappear <g>.

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Hum, I found it does work after all, but only when called from the Windows Command prompt! If I call it from a MinGW shell I get an error (which was what originally made think one wasn't supposed to use -run). Substituting dmd for the very printargs.exe, here's what is found:
>>
>> When one runs rdmd from the Win CMD shell:
>>
>>  > rdmd dummy.d
>> ARGS: 5 [C:\devel\D.tools\dmd\bin\dmd.exe,-quiet,dummy.d,-ofc:\Home\phoenix\
>> LOCALS~1\Temp\dummy-phoenix-0-0-A46C236CDE107E3B9F053881E4257C2D.exe,-odc:\H 
>>
>> ome\phoenix\LOCALS~1\Temp\]
>>
>> (DMD would run fine)
>> But when one runs rdmd from the MinGW bash shell:
>>
>> $ rdmd dummy.d
>> ARGS: 5 [c:\devel\D.tools\dmd\bin\dmd.exe,-quiet,dummy.d,-ofc:/Home/phoenix/
>> LOCALS~1/Temp\dummy-phoenix-0-0-A46C236CDE107E3B9F053881E4257C2D.exe,-odc:/H 
>>
>> ome/phoenix/LOCALS~1/Temp\]
>>
>> Some of the slashes are inverted, and that makes OPTLINK choke. Weird. How does rdmd have this different behaviour, I mean, how does it even know it's running under a different shell/environ/whatever? :/
> 
> It doesn't know. The mingw shell is buggy. It doesn't follow Windows conventions, and so screws up programs that do. I've gotten numerous mysterious bug reports over the years that eventually got traced back to the mingw shell. Stop using it, and the problems disappear <g>.

What "Windows conventions" it doesn't follow?
Any way, for what I see, MingW (or perhaps, more corretly, MSYS) "sanitizes" each program (at least non-Unix ones) that is run by the bash shell by adapting the program arguments and environment variables from Unix paths to Windows paths. In this process the TEMP env var is translated incorrectly from "/tmp" to "c:/home/phoenix/LOCALS~1/Temp" (the slashes remain Unix ones)

>  Stop using it, and the problems disappear <g>.
Not something I am in any way willing to do. Unless it's changing to Cygwin (if it is any different).
Hum, now that I see it, Mingw seems to be a bit stale, the last version of MSYS is from 2004. Maybe I should haste my change to Cygwin? (I was already thinking of changing, but for other reasons)

And by the way, how about folding rdmd's functionality into dmd itself? It shouldn't take too long. :)



-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Walter Bright wrote:
>> It doesn't know. The mingw shell is buggy. It doesn't follow Windows conventions, and so screws up programs that do. I've gotten numerous mysterious bug reports over the years that eventually got traced back to the mingw shell. Stop using it, and the problems disappear <g>.
> What "Windows conventions" it doesn't follow?

Beats me. I just find that, over and over, when people stop using the mingw shell for Windows programs their problems go away.

>  >  Stop using it, and the problems disappear <g>.
> Not something I am in any way willing to do.

Trying to turn Windows into unix is never going to work right.

> And by the way, how about folding rdmd's functionality into dmd itself? It shouldn't take too long. :)

That'll happen eventually.

In article <e5t8qi$2gek$1@digitaldaemon.com>, Walter Bright says...
>
>Bruno Medeiros wrote:
>> Walter Bright wrote:
[...]
>
>> And by the way, how about folding rdmd's functionality into dmd itself? It shouldn't take too long. :)
>
>That'll happen eventually.

You should fix the linker bug of the map file generation on windows, first.

Ciao

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> It doesn't know. The mingw shell is buggy. It doesn't follow Windows conventions, and so screws up programs that do. I've gotten numerous mysterious bug reports over the years that eventually got traced back to the mingw shell. Stop using it, and the problems disappear <g>.
>> What "Windows conventions" it doesn't follow?
> 
> Beats me. I just find that, over and over, when people stop using the mingw shell for Windows programs their problems go away.
> 
>>  >  Stop using it, and the problems disappear <g>.
>> Not something I am in any way willing to do.
> 
> Trying to turn Windows into unix is never going to work right.
> 

Disagreed, it is already working good enough! I've been using for a while both the MingW tools and (more recently) the MingW shell itself, and it's so more useful than not having it that it would take a lot more bugs than that to make me change.

>> And by the way, how about folding rdmd's functionality into dmd itself? It shouldn't take too long. :)
> 
> That'll happen eventually.

Nice. :)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D