My apologies to Mikael for the redundant reply in your mailbox. I sometimes forget to change the "To" field when using GMail to reply to the list....

On Tue, Jan 17, 2012 at 4:26 AM, Mikael mikael.rcv@gmail.com wrote:

Hi,

Remember to post this in bugzilla.

Right, thanks for bringing that up.

Could a difference in MingW version between the 4.6.0 and 4.6.2 binary have led to the error?

I don't thinks so, based on my limited debugging.

As a simple debug measure I suppose you could diff the code for/underlying shell-command of 4.6.0 and 4.6.2.

Marc has already responded to this thread with code for me to test, which I will do next. I had typed out a long response with more information about some debugging I had done. It may be irrelevant now that Marc has responded, but just in case it isn't I'll include it here anyway:

---------------------------------------------

I built Gambit 4.6.2 with debugging info and optimization at -O0 so that I could debug gsi with gdb. I ran gdb in the MinGW Msys shell, and executed (shell-command "ls 1 2 3"). I had set a breakpoint at the end of argv_to_ccmd in os_io.c, after discovering that it was being called when shell-command was executed. You can see below that the command string returned from argv_to_ccmd is "sh -c ls 1 2 3".

Breakpoint 1, argv_to_ccmd (argv=0x1280238) at os_io.c:6818 6818 return ccmd; (gdb) p ccmd $1 = 0x3eff38 "sh -c ls 1 2 3"

This looked to me as if it would cause a problem (because there were no quotes around "ls 1 2 3". And indeed, on line 7173 of os_io.c, that exact string is being passed to CreateProcess as the command line:

Breakpoint 2, ___device_stream_setup_from_process (dev=0x22e2e8, dgroup=0x3e4208, argv=0x1280238, env=0x0, dir=0x12840c8 "C:\MinGW\msys\1.0\updates\src\gambit\gambc-v4_6_2-devel\", options=16) at os_io.c:7173 7173 if (si.hStdError == INVALID_HANDLE_VALUE || (gdb) pccmd $2 = 0x3eff38 "sh -c ls 1 2 3"

I thought, surely this would not work correctly (and, of course it doesn't).

I noticed that there were some #ifndefs in the code which were testing the value of ___DOUBLE_QUOTE_PROGRAM_ARGS. But ___DOUBLE_QUOTE_PROGRAM_ARGS didn't ever seem to be defined. So I thought I'd try to define it, rebuild and see what the results were.

Again, I set a breakpoint at the end of argv_to_ccmd() in os_io.c (just before the return statement around line 6818

p ccmd $2 = 0x12845e8 ""sh" "-c" "ls 1 2 3"" (gdb) c Continuing. ls: 1: No such file or directory ls: 2: No such file or directory ls: 3: No such file or directory

You can see, that after continuing, this version gives the correct result from gsi (no such file or directory for the files "1" "2" and "3"), but causes problems with gambc-cc.bat when gsc calls it I get the following error message:

gambc-cc.bat unknown operation ""obj""

I suspect that is because the "sh" and "-c" were quoted as well. I wonder if the problem may be related to changes made last March, as discussed in this thread:

https://mercure.iro.umontreal.ca/pipermail/gambit-list/2011-March/004894.htm...

... but I haven't yet chased down the changes that Marc refers to at the end of that thread (for further investigation).

Mikael

2012/1/17 REPLeffect repleffect@gmail.com

...

The shell-command procedure under the MinGW build of Gambit 4.6.2 seems to be broken. When running gsi under the MinGW MSys shell (by running gsi.exe -:d-), things worked fine under Gambit 4.6.0 (as shown below).  However, in Gambit 4.6.2, it appears that only the program name passed in the shell command is being recognized.  Thus, I could run (shell-command "ls 1 2 3") while in a directory where no such files existed, and I got the contents of the directory (as if the command had only been "ls", with no arguments).

==== Output running under Msys: (gsi.exe -:d-) ==========

Gambit v4.6.0

> (shell-command "ls 1 2 3")  ls: 1: No such file or directory  ls: 2: No such file or directory  ls: 3: No such file or directory  512  >

Gambit v4.6.2

> (shell-command "ls 1 2 3")  INSTALL.txt  LGPL.txt  LICENSE-2.0.txt  README  bin  config.guess  config.log  config.status  config.sub  configure  configure.ac  doc  examples  gsc  gsc-comp.exe  gsi  include  install-sh  lib  makefile  makefile.in  misc  mkidirs  prebuilt  relpath  tests  0  >

The results get even worse when running Gambit 4.6.2 directly from the Windows start menu.  Here again, version 4.6.0 does what I expected.  However, when I run version 4.6.2, I can't get the shell-command to work no matter what command I pass it:

====== Output running gsi.exe directly from the Windows Start Menu: ======

Gambit v4.6.0

> (shell-command "dir 1 2 3")   Volume in drive C has no label.   Volume Serial Number is 14C2-1C72

Directory of C:\test\Gambit-C\v4_6_0\v4.6.0\bin

Directory of C:\test\Gambit-C\v4_6_0\v4.6.0\bin

Directory of C:\test\Gambit-C\v4_6_0\v4.6.0\bin

File Not Found  256  >

Gambit v4.6.2

> (shell-command "dir 1 2 3")  *** ERROR IN (console)@1.1 -- No such file or directory  (open-process   '(path: "sh" arguments: ("-c" "dir 1 2 3") stdin-redirection: #f stdout-red...  )  1>

> (shell-command "dir")  *** ERROR IN (console)@5.1 -- No such file or directory  (open-process   '(path: "sh" arguments: ("-c" "dir") stdin-redirection: #f stdout-redirecti...  )  1>

---

All of these tests were run against the current prebuilt versions of Gambit 4.6.0 and 4.6.2 downloaded from Gambit's web site.

I'll be happy to test any patches or other changes needed to fix this problem. _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

---

Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

On Tue, Jan 17, 2012 at 10:07 AM, Marc Feeley feeley@iro.umontreal.ca wrote:

On 2012-01-17, at 3:01 AM, REPLeffect wrote:

...

All of these tests were run against the current prebuilt versions of Gambit 4.6.0 and 4.6.2 downloaded from Gambit's web site.

I'll be happy to test any patches or other changes needed to fix this problem.

The implementation of the shell-command procedure is tricky.  On Unix, the tradition of using /bin/sh is maintained.  On Windows there are options: CMD.EXE, COMMAND.COM and sh (when MSYS or CYGWIN are installed).  If MSYS or CYGWIN are installed and Gambit was launched from a shell in those environments, then it is reasonable to think that the user is executing shell-commands which make sense for those environments (for example, using "ls" instead of "dir").  Other users might expect or prefer the default Windows shell.

The implementation of shell-command tries to figure this out to start the correct shell to process the command.  The logic is a bit brittle, and as you have experienced, it guessed the wrong shell.

I'm attaching below a new implementation of shell-command which does a better job.  Can you try it out and let me know if it works for you?  If you know of better heuristics, let me know!

Marc

(define ##shell-program #f)

(define (##get-shell-program)

(define unix-shell-program    '("/bin/sh" . "-c"))  (define windows-shell-program '("CMD.EXE" . "/C"))  (define default-shell-program '("sh"      . "-c"))

(or ##shell-program      (let ((sp             (if (##file-exists? (##car unix-shell-program))                 unix-shell-program                 (if (##getenv "HOME" #f)                     default-shell-program                     (let ((comspec (##getenv "COMSPEC" #f)))                       (if comspec                           (##cons comspec "/C")                           windows-shell-program))))))        (set! ##shell-program sp)        sp)))

(define (shell-command cmd)  (let* ((shell-prog          (##get-shell-program))         (path-or-settings          (##list path: (##car shell-prog)                  arguments:                  (##list                   (##cdr shell-prog)                   cmd)                  stdin-redirection: #f                  stdout-redirection: #f                  stderr-redirection: #f)))    (##open-process-generic     3;(macro-direction-inout)     #t     (lambda (port)       (##close-port port)       (##process-status port))     open-process     path-or-settings)))

Marc,

That implemenation fixes the problem where running gsi in the standard cmd.exe shell had failed before, and I get the results I would expect when running (shell-command "dir 1 2 3").

However, when I run gsi from the MinGW Msys shell, and then run (shell-command "ls 1 2 3"), I still get the results you would expect from running (shell-command "ls") -- that is, there is no error, and it displays the contents of the current directory, rather than trying to list the files named "1" "2" and "3". Running under gdb again, I see that the command string returned from argv_to_cmd is "sh -c ls 1 2 3" -- just as it was in my previous testing.

So, next I ran gdb in the cmd.exe shell, and debugged gsi from there (setting the same breakpoint in argv_to_cmd):

Breakpoint 1, argv_to_ccmd (argv=0x1281648) at os_io.c:6817 6817 return ccmd; (gdb) p ccmd $1 = 0x1281740 "C:\WINDOWS\system32\cmd.exe /C dir 1 2 3"

Here again, the command being executed does not have quotes around it. It just so happens that under cmd.exe, that doesn't matter. You get the same results if you execute this:

cmd.exe /c dir 1 2 3

that you get if you execute this:

cmd.exe /c "dir 1 2 3"

However, if from the MinGW Msys shell you execute this:

sh -c ls 1 2 3

You will *not* get a listing of the files named "1" "2" and "3". You will get a listing of the current directory, just as if you had executed "sh -c ls".

However, executing this:

sh -c "ls 1 2 3"

gives the results you would expect:

ls: 1: No such file or directory ls: 2: No such file or directory ls: 3: No such file or directory