From: Mike T. <miketh@ParadigmGeo.com> - 2006-06-12 23:36:01
|
Hi all. Thanks Yaroslav for the report and Juho for the comments. As I wrote the code I'd best try to make a start on fixing these issues this evening. I need to clarify some stuff first as I think I've misunderstood the meaning of the (:input :output :error) keyword settings; >=20 > Yaroslav Kavenchuk <kav...@je...> writes: > > 1. all streams (:input :output :error) is nil (default value) > >=20 > > From (describe 'run-program): "If NIL, /dev/null is used." > [... outputs to stdout ... ] Are you saying that the correct default value of (:input :output :error) is nil (rather than t) and that if nil, then the corresponding stdio should go to a null stream (rather than being ignored)? > > 2. any stream is t > >=20 > > From (describe 'run-program): > > "If T, the standard input[output] for the current process=20 > is inherited." > [... errors ... ] > > 4. stream > >=20 > > * (with-open-file (f "test-output" :direction :output) > > (run-program "c:/gnu/bin/sh.exe" (list "-c" "ls /") > > :output f)) > [... outputs to stdout ... ] >=20 > These problems are probably caused by the somewhat strange fd=20 > handling in the win32 implementation for spawn=20 > (src/runtime/run-program.c). At least I don't see how the=20 > code there could work the same way that the Unix code does. Could you please clarify any issues you see regarding the fd handling, Juho?=20 Cheers Mike Thomas. |
From: Mike T. <mi...@pa...> - 2006-06-13 22:13:07
|
Hi Juho.=20 > The code is supposed to use the in/out/err fds as the=20 > stdin/stdout/stderr of the spawned process. >=20 > If I understand the win32 code correctly, it instead creates=20 > a new pipe (fd pair) for each of the fds, dup2's one end of=20 > the pipes on top of in/out/err, and then discards the other=20 > end. Which doesn't make any > sense: if the other end of the pipe isn't used for anything,=20 > what good is it? And how is the spawned process going to know=20 > how to use the non-discarded end of the pipes as stdin/stdout/stderr? >=20 > It should probably be more like: backup std* with dup, dup2=20 > in/out/err onto std*, spawn, dup2 the the backups back to=20 > std*. (But I know absolutely nothing of win32 systems=20 > programming, so take this with a grain of salt). Thanks - I think I was seeing this from the wrong perspective. I'll get to it when I can - if not this morning then a couple of days time. Cheers Mike Thomas. |
From: Mike T. <miketh@ParadigmGeo.com> - 2006-06-14 06:09:27
Attachments:
diff.txt
|
Hi Yaroslav/Juho. The following tests based on Yaroslav's bug report now work with 0.9.13 patched per the attached diff. I've included a recursive instance of sbcl itself in the tests. Yaroslav, if you absolutely can't rebuild 0.9.13 yourself with these patches, please let me know and I'll send you a new binary tomorrow (I'm on Australian time). Please let me know how you go, whatever happens. Juho, if no major issues, please apply to CVS. Thanks for your excellent feedback! Cheers Mike Thomas =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UNDER Win32 command shell =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * (setf t3p (run-program "notepad" nil :wait t :search t :output "t4")) ; in: LAMBDA NIL ; (SETF T3P (RUN-PROGRAM "notepad" NIL :WAIT T :SEARCH T :OUTPUT "t4")) ; =3D=3D> ; (SETQ T3P (RUN-PROGRAM "notepad" NIL :WAIT T :SEARCH T :OUTPUT "t4")) ; ; caught WARNING: ; undefined variable: T3P ; ; caught WARNING: ; This variable is undefined: ; T3P ; ; compilation unit finished ; caught 2 WARNING conditions #<SB-IMPL::PROCESS :EXITED 0> * (delete-file "t4") T * sb-impl::*active-processes* (#<SB-IMPL::PROCESS :EXITED 0>) * (process-close t3p) #<SB-IMPL::PROCESS :EXITED 0> * sb-impl::*active-processes* NIL * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UNDER MSYS sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D $ sbcl This is SBCL 0.9.13, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. os_map: 3, 0x1000, 02000000, 0x1000. os_map: 3, 0x2000, 05000000, 0x1000. os_map: 3, 0x3000, 09000000, 0x15c8000. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" * (run-program "sh.exe" nil :search t) #<SB-IMPL::PROCESS :EXITED 0> * (run-program "sh.exe" nil :search t :output t) #<SB-IMPL::PROCESS :EXITED 0> * (run-program "sh.exe" (list "-c" "ls /") :search t :output t) BUGS local-target-features.lisp-expr COPYING make-config.sh CREDITS make-genesis-2.lisp CVS make-genesis-2.sh INSTALL make-host-1.lisp NEWS make-host-1.sh OPTIMIZATIONS make-host-2.lisp PRINCIPLES make-host-2.sh README make-target-1.sh STYLE make-target-2.lisp SUPPORT make-target-2.sh TLA make-target-contrib.sh TODO make.log base-target-features.lisp-expr make.sh binary-distribution.sh obj build-order.lisp-expr output clean.sh package-data-list.lisp-expr common-lisp-exports.lisp-expr pubring.pgp contrib slam.sh diff.txt source-distribution.sh diff.txt~ src distclean.sh tagify.sh doc tests find-gnumake.sh tools-for-build html-distribution.sh version.lisp-expr install.sh wc.sh #<SB-IMPL::PROCESS :EXITED 0> * (run-program "sh.exe" (list "-c" "ls /") :search t :output #P"test-output") #<SB-IMPL::PROCESS :EXITED 0> * (probe-file "test-output") #P"c:\\development\\src\\sbcl-0.9.13\\test-output" * (with-open-file (f "test-output" ) (file-length f)) 749 * (delete-file "test-output") T * (run-program "sbcl" nil :search t :output t :input t :error t) This is SBCL 0.9.13, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. os_map: 7, 0x1000, 02000000, 0x1000. os_map: 7, 0x2000, 05000000, 0x1000. os_map: 7, 0x3000, 09000000, 0x15c8000. This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" * (+ 1 2) 3 * (quit) #<SB-IMPL::PROCESS :EXITED 0> * (quit) $ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D |
From: Yaroslav K. <kav...@je...> - 2006-06-14 07:08:32
|
Mike Thomas wrote: > > Please let me know how you go, whatever happens. > Excellent! All my small tests passed. Many thanks! -- WBR, Yaroslav Kavenchuk. |
From: Yaroslav K. <kav...@je...> - 2006-06-14 07:36:38
|
Yaroslav Kavenchuk wrote: > Excellent! All my small tests passed. > > Many thanks! Oops, one bug: 1. test: * (run-program "c:/gnu/bin/sh.exe" nil :output t :input t) Kavenchuk_Yaroslav@STNT067 c:/Documents and Settings/Kavenchuk_Yaroslav $ ls / COPYING MinGW contrib doc home info libexec m.ico manifest msys.bat share usr COPYING.LIB bin cvsroot etc include lib local man mingw32 msys.ico uninstall Kavenchuk_Yaroslav@STNT067 c:/Documents and Settings/Kavenchuk_Yaroslav $ exit exit #<SB-IMPL::PROCESS :EXITED 0> 2. bug: * (run-program "c:/gnu/bin/sh.exe" nil :output sb-sys:*stdout* :input sb-sys:*stdin*) SBCL hangs -- WBR, Yaroslav Kavenchuk. |
From: Juho S. <js...@ik...> - 2006-08-04 15:02:39
|
"Mike Thomas" <miketh@ParadigmGeo.com> writes: > Juho, if no major issues, please apply to CVS. Hi, I don't understand the following changes to run-program.lisp. Could you explain what they're for? > @@ -845,22 +845,29 @@ > (when (< handle 0) > (error "Couldn't spawn program: ~A" (strerror))) > (setf proc > - (if wait > - (make-process :%status :exited > - :exit-code handle) > - (make-process :pid handle > - :%status :running > - :input input-stream > - :output output-stream > - :error error-stream > - :status-hook status-hook > - :cookie cookie)))))))))) > - ;; FIXME: this should probably use PROCESS-WAIT instead instead > - ;; of special argument to SPAWN. > - (unless wait > - (push proc *active-processes*)) > - (when (and wait status-hook) > - (funcall status-hook proc)) > + (if wait > + (make-process :pid handle > + :%status :exited > + :input input-stream > + :output output-stream > + :error error-stream > + :status-hook status-hook > + :cookie cookie > + :exit-code handle) > + (make-process :pid handle > + :%status :running > + :input input-stream > + :output output-stream > + :error error-stream > + :status-hook status-hook > + :cookie cookie))) > + (push proc *active-processes*))))))) > + (dolist (fd *close-in-parent*) > + (sb-unix:unix-close fd))) > + (unless proc > + (dolist (fd *close-on-error*) > + (sb-unix:unix-close fd))) > + > proc)) > > ;;; Install a handler for any input that shows up on the file -- Juho Snellman |
From: Yaroslav K. <kav...@tu...> - 2006-08-13 21:40:21
|
If change part of your patch for src/runtime/run-program.c from > + if ( out >= 0 ) { > + if ( _dup2 ( out, _fileno ( stdout ) ) != 0 ) return (HANDLE)-1; > + } > + if ( in >= 0 ) { > + if ( _dup2 ( in, _fileno ( stdin ) ) != 0 ) return (HANDLE)-1; > + } > + if ( err >= 0 ) { > + if ( _dup2 ( err, _fileno ( stderr ) ) != 0 ) return (HANDLE)-1; > + } to > + if ( ( out >= 0 ) && ( out != _fileno ( stdout ) ) ) { > + if ( _dup2 ( out, _fileno ( stdout ) ) != 0 ) return (HANDLE)-1; > + } > + if ( ( in >= 0 ) && ( in != _fileno ( stdin ) ) ) { > + if ( _dup2 ( in, _fileno ( stdin ) ) != 0 ) return (HANDLE)-1; > + } > + if ( ( err >= 0 ) && ( err != _fileno ( stderr ) ) ) { > + if ( _dup2 ( err, _fileno ( stderr ) ) != 0 ) return (HANDLE)-1; > + } All works! Many thanks! -- WBR, Yaroslav Kavenchuk. |
From: Mike T. <mi...@pa...> - 2006-06-15 00:05:44
|
Hi Yaroslav. =20 > 2. bug: >=20 > * (run-program "c:/gnu/bin/sh.exe" nil :output sb-sys:*stdout* > :input sb-sys:*stdin*) I don't have an immediate answer to this one I'm sorry - there seems to be a problem with duping the stdio handles, perhaps buffering. I tried flushing before duping the handles but that didn't work so I'll have to think about it and experiment - no idea when it will be fixed. Cheers Mike Thomas. |
From: Mike T. <mi...@pa...> - 2006-08-07 02:12:56
|
Hi Juho. =20 > Hi, I don't understand the following changes to=20 > run-program.lisp. Could you explain what they're for? It's been a while, but prior to those changes output from 'waited on' processes was lost. The changes also clean up previously ignored *close-X-X* fd's. Sorry for being brief but for the past month I've been fighting a rather nasty disease called Q Fever which I seem to have acquired from an arachnid/insect bite while mowing the lawn. That's Australia for you. Cheers Mike Thomas. |
From: Mike T. <mi...@pa...> - 2006-08-13 21:53:28
|
> Many thanks! And especially you Yaroslav! Mike Thomas. |
From: Yaroslav K. <kav...@je...> - 2006-06-13 06:42:10
|
Mike Thomas wrote: > Are you saying that the correct default value of (:input :output :error) > is nil (rather than t) and that if nil, then the corresponding stdio > should go to a null stream (rather than being ignored)? Yes. http://www.sbcl.org/manual/Support-For-Unix.html#Support%20For%20Unix -- WBR, Yaroslav Kavenchuk. |
From: Juho S. <js...@ik...> - 2006-06-13 07:41:51
|
"Mike Thomas" <miketh@ParadigmGeo.com> writes: > Are you saying that the correct default value of (:input :output :error) > is nil (rather than t) and that if nil, then the corresponding stdio > should go to a null stream (rather than being ignored)? Yes. > Could you please clarify any issues you see regarding the fd handling, > Juho? The code is supposed to use the in/out/err fds as the stdin/stdout/stderr of the spawned process. If I understand the win32 code correctly, it instead creates a new pipe (fd pair) for each of the fds, dup2's one end of the pipes on top of in/out/err, and then discards the other end. Which doesn't make any sense: if the other end of the pipe isn't used for anything, what good is it? And how is the spawned process going to know how to use the non-discarded end of the pipes as stdin/stdout/stderr? It should probably be more like: backup std* with dup, dup2 in/out/err onto std*, spawn, dup2 the the backups back to std*. (But I know absolutely nothing of win32 systems programming, so take this with a grain of salt). -- Juho Snellman |