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)))