www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - BUG: rdmd cmd line argument bug

reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
May 28 2006
parent reply Dave <Dave_member pathlink.com> writes:
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.
May 29 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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



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
May 30 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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>.
Jun 02 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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>.



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
Jun 03 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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>.






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.
Jun 03 2006
next sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
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
Jun 06 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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>.






 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
Jun 11 2006