sbcl-devel

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 <kavenchuk@...> 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.

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.

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.

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.

"Mike Thomas" <miketh@...> 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