At 12:54 AM 12/24/2004 -0500, Pierre A. Humblet wrote:
At 12:25 AM 12/24/2004 -0500, Christopher Faylor wrote:
On Thu, Dec 23, 2004 at 11:59:59PM -0500, Pierre A. Humblet wrote:
At 11:35 PM 12/23/2004 -0500, Christopher Faylor wrote:
I don't think you need it. You just need to tell a process
On Fri, Dec 24, 2004 at 08:40:29AM -0500, Pierre A. Humblet wrote:
At 12:54 AM 12/24/2004 -0500, Pierre A. Humblet wrote:
I think the way out is as follows:
Toward the end of spawn_guts:
ciresrv.sync (myself, INFINITE); [always]
if (wait_for_myself)
waitpid (myself-pid, dummy, 0);
[For
I have run some more tests with a built from cvs this afternoon
and peeked at some of the changes, so here is some feedback.
When a process is terminated from Windows, the reported exit code
is 0. This can easily be fixed by initializing exitcode to
the value it should take when a process is
On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A. Humblet wrote:
I have run some more tests with a built from cvs this afternoon
and peeked at some of the changes, so here is some feedback.
When a process is terminated from Windows, the reported exit code
is 0. This can easily be fixed by
At 09:27 PM 12/23/2004 -0500, Christopher Faylor wrote:
On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A. Humblet wrote:
The side effect of doing things this way is that the program will seem
to have exited with a SIGTERM value if it calls ExitProcess, too.
That is a depature from previous
On Thu, Dec 23, 2004 at 09:54:20PM -0500, Pierre A. Humblet wrote:
At 09:27 PM 12/23/2004 -0500, Christopher Faylor wrote:
On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A. Humblet wrote:
The side effect of doing things this way is that the program will seem
to have exited with a SIGTERM value
At 10:50 PM 12/23/2004 -0500, Christopher Faylor wrote:
On Thu, Dec 23, 2004 at 09:54:20PM -0500, Pierre A. Humblet wrote:
At 09:27 PM 12/23/2004 -0500, Christopher Faylor wrote:
On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A. Humblet wrote:
FWIW, I modified cygwin so that it seems as if with
On Thu, Dec 23, 2004 at 11:05:50PM -0500, Pierre A. Humblet wrote:
At 10:50 PM 12/23/2004 -0500, Christopher Faylor wrote:
On Thu, Dec 23, 2004 at 09:54:20PM -0500, Pierre A. Humblet wrote:
At 09:27 PM 12/23/2004 -0500, Christopher Faylor wrote:
On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A.
At 11:35 PM 12/23/2004 -0500, Christopher Faylor wrote:
On Thu, Dec 23, 2004 at 11:05:50PM -0500, Pierre A. Humblet wrote:
At 10:50 PM 12/23/2004 -0500, Christopher Faylor wrote:
On Thu, Dec 23, 2004 at 09:54:20PM -0500, Pierre A. Humblet wrote:
At 09:27 PM 12/23/2004 -0500, Christopher Faylor
On Thu, Dec 23, 2004 at 11:59:59PM -0500, Pierre A. Humblet wrote:
At 11:35 PM 12/23/2004 -0500, Christopher Faylor wrote:
I don't think you need it. You just need to tell a process which is
about to exec after having been execed to make sure that its
wr_proc_pipe is valid.
Yes, that's the key.
At 12:25 AM 12/24/2004 -0500, Christopher Faylor wrote:
On Thu, Dec 23, 2004 at 11:59:59PM -0500, Pierre A. Humblet wrote:
At 11:35 PM 12/23/2004 -0500, Christopher Faylor wrote:
I don't think you need it. You just need to tell a process which is
about to exec after having been execed to make
I tried my spawn(P_DETACH) example (updated since yesterday)
with the latest snapshot, this time on NT.
#include stdio.h
#include unistd.h
#include process.h
main()
{
spawnl(_P_DETACH, /c/WINNT/system32/notepad, notepad, 0);
printf(Spawn done\n);
/* Keep working */
sleep(10);
On Wed, Dec 22, 2004 at 11:13:30AM -0500, Pierre A. Humblet wrote:
I tried my spawn(P_DETACH) example (updated since yesterday)
with the latest snapshot, this time on NT.
#include stdio.h
#include unistd.h
#include process.h
main()
{
spawnl(_P_DETACH, /c/WINNT/system32/notepad, notepad, 0);
Pierre A. Humblet wrote:
When running try_spawn with the snapshot, during the sleep period
ps reports
690 443 6902320 11054 10:32:21 defunct
464 690 6904640 11054 10:32:21
/c/WINNT/system32/notepad
FWIW, I was thinking about this
Pierre A. Humblet wrote:
Pierre A. Humblet wrote:
When running try_spawn with the snapshot, during the sleep period
ps reports
690 443 6902320 11054 10:32:21 defunct
464 690 6904640 11054 10:32:21
/c/WINNT/system32/notepad
On Tue, Dec 14, 2004 at 09:41:41AM -0500, Pierre A. Humblet wrote:
Christopher Faylor wrote:
With the current CVS, I am seeing the same (suboptimal) behavior on
Windows Me that I do in 1.5.12.
If I type a bunch of sleep 60 at the command line, then bash won't
exit until the last sleep 60 has
With the current CVS, I am seeing the same (suboptimal) behavior on
Windows Me that I do in 1.5.12.
If I type a bunch of sleep 60 at the command line, then bash won't
exit until the last sleep 60 has terminated. I can't explain why this
is. It doesn't work that way on XP, of course.
While bash
Christopher Faylor wrote:
With the current CVS, I am seeing the same (suboptimal) behavior on
Windows Me that I do in 1.5.12.
If I type a bunch of sleep 60 at the command line, then bash won't
exit until the last sleep 60 has terminated. I can't explain why this
is. It doesn't work
At 12:43 AM 12/4/2004 -0500, Christopher Faylor wrote:
I wrote a simple test case to check this and I don't see it -- on XP. I
can't easily run Me anymore. Does the attached program demonstrate this
behavior when you run it? It should re-exec itself every time you hit
CTRL-C.
That test case
At 12:33 PM 12/4/2004 -0500, Christopher Faylor wrote:
On Sat, Dec 04, 2004 at 11:45:28AM -0500, Pierre A. Humblet wrote:
At 12:43 AM 12/4/2004 -0500, Christopher Faylor wrote:
I wrote a simple test case to check this and I don't see it -- on XP. I
can't easily run Me anymore. Does the attached
On Sat, Dec 04, 2004 at 01:01:11PM -0500, Pierre A. Humblet wrote:
At 12:33 PM 12/4/2004 -0500, Christopher Faylor wrote:
On Sat, Dec 04, 2004 at 11:45:28AM -0500, Pierre A. Humblet wrote:
At 12:43 AM 12/4/2004 -0500, Christopher Faylor wrote:
I wrote a simple test case to check this and I don't
[and now the more detailed reply]
On Thu, Dec 02, 2004 at 09:13:11PM -0500, Pierre A. Humblet wrote:
At 11:29 PM 11/25/2004 -0500, Christopher Faylor wrote:
I have downloaded and run a recent snapshot on WinME,
CYGWIN_ME-4.90 hpn5170 1.5.13s(0.116/4/2) 20041125 23:34:52 i686 unknown
unknown
On Thu, Dec 02, 2004 at 09:13:11PM -0500, Pierre A. Humblet wrote:
- Non cygwin processes started by cygwin are not shown by ps
anymore and cannot be killed.
- spawn(P_DETACH) does not work correctly when spawning non-cygwin
processes.
This is due to using a pipe to detect process
On Sat, Nov 20, 2004 at 01:23:39AM -0500, Christopher Faylor wrote:
On Tue, Nov 16, 2004 at 10:56:40AM -0500, Christopher Faylor wrote:
The simplification of the code from removing all of the reparenting
considerations is not something that I'm going to give up on easily.
Well, the code seems to
On Sat, 20 Nov 2004, Christopher Faylor wrote:
Here's the good news/bad news.
On Tue, Nov 16, 2004 at 10:56:40AM -0500, Christopher Faylor wrote:
The simplification of the code from removing all of the reparenting
considerations is not something that I'm going to give up on easily.
Well,
On Mon, Nov 22, 2004 at 12:46:46PM -0500, Igor Pechtchanski wrote:
Can the code simply propagate the actual exit code into the exitcode
field (since Windows programs don't know about signals)?
And who would use it? How would a UNIX program know that the negative
exit code represented a windows
On Mon, 22 Nov 2004, Christopher Faylor wrote:
On Mon, Nov 22, 2004 at 12:46:46PM -0500, Igor Pechtchanski wrote:
Can the code simply propagate the actual exit code into the exitcode
field (since Windows programs don't know about signals)?
And who would use it? How would a UNIX program know
On Mon, Nov 22, 2004 at 01:20:45PM -0500, Igor Pechtchanski wrote:
On Mon, 22 Nov 2004, Christopher Faylor wrote:
On Mon, Nov 22, 2004 at 12:46:46PM -0500, Igor Pechtchanski wrote:
Can the code simply propagate the actual exit code into the exitcode
field (since Windows programs don't know
On Mon, 22 Nov 2004, Christopher Faylor wrote:
On Mon, Nov 22, 2004 at 01:20:45PM -0500, Igor Pechtchanski wrote:
On Mon, 22 Nov 2004, Christopher Faylor wrote:
On Mon, Nov 22, 2004 at 12:46:46PM -0500, Igor Pechtchanski wrote:
Can the code simply propagate the actual exit code into the
On Mon, Nov 22, 2004 at 01:36:45PM -0500, Igor Pechtchanski wrote:
On Mon, 22 Nov 2004, Christopher Faylor wrote:
*I've also added an 'exitcode' field to _pinfo so that a Cygwin process
*will set the error (sic) code in a UNIX fashion based on whether it is
*exiting *due to a signal or with a
At 01:23 AM 11/20/2004 -0500, Christopher Faylor wrote:
Here's the good news/bad news.
On Tue, Nov 16, 2004 at 10:56:40AM -0500, Christopher Faylor wrote:
The simplification of the code from removing all of the reparenting
considerations is not something that I'm going to give up on easily.
Here's the good news/bad news.
On Tue, Nov 16, 2004 at 10:56:40AM -0500, Christopher Faylor wrote:
The simplification of the code from removing all of the reparenting
considerations is not something that I'm going to give up on easily.
Well, the code seems to be slightly faster now than the old
On Sun, Nov 14, 2004 at 12:11:58AM -0500, Christopher Faylor wrote:
When I get the code to a point that it can run configure, I'll do a
benchmark and see how bad this technique is. If there is not a
noticeable degradation, I think I'll probably duplicate the scenario of
last year and checkin this
At 12:11 AM 11/14/2004 -0500, Christopher Faylor wrote:
When you first mentioned this, I had an idea that maybe we could be
waiting on something else besides a process handle which would be
inherited by any subprocesses. I thought that maybe we could somehow
use a mutex but there would always be
At 01:03 PM 11/14/2004 -0500, Christopher Faylor wrote:
On Sun, Nov 14, 2004 at 12:34:30PM -0500, Pierre A. Humblet wrote:
At 12:11 AM 11/14/2004 -0500, Christopher Faylor wrote:
BTW, have you ever tried using select, having a connection from the
parent to the child?
select involves polling or
On Sun, Nov 14, 2004 at 01:23:59PM -0500, Pierre A. Humblet wrote:
At 01:03 PM 11/14/2004 -0500, Christopher Faylor wrote:
On Sun, Nov 14, 2004 at 12:34:30PM -0500, Pierre A. Humblet wrote:
At 12:11 AM 11/14/2004 -0500, Christopher Faylor wrote:
BTW, have you ever tried using select, having a
On Thu, Nov 11, 2004 at 11:52:25PM -0500, Pierre A. Humblet wrote:
At 11:33 PM 11/11/2004 -0500, Christopher Faylor wrote:
On Thu, Nov 11, 2004 at 10:48:57PM -0500, Pierre A. Humblet wrote:
Now that 1.5.12 is out, here is a patch to fix the PROCESS_DUP_HANDLE
security hole. It uses a new approach
Now that 1.5.12 is out, here is a patch to fix the
PROCESS_DUP_HANDLE security hole. It uses a new approach
to reparenting: the parent duplicates the exec'ed process
handle when signaled by the child.
It also handles correctly the case of a quick re-exec
(2 simultaneous reparenting), which is
On Thu, Nov 11, 2004 at 10:48:57PM -0500, Pierre A. Humblet wrote:
P.S.: I have no news about the recent patch to /bin/kill -f
That is because I was sure that I'd used 'kill -f' to kill windows pids
in the past and wanted to check your patch. I haven't been near a
WinMe system in a while,
On Thu, Nov 11, 2004 at 10:48:57PM -0500, Pierre A. Humblet wrote:
Now that 1.5.12 is out, here is a patch to fix the PROCESS_DUP_HANDLE
security hole. It uses a new approach to reparenting: the parent
duplicates the exec'ed process handle when signaled by the child.
Can you refresh my memory (a
At 11:24 PM 11/11/2004 -0500, Christopher Faylor wrote:
On Thu, Nov 11, 2004 at 10:48:57PM -0500, Pierre A. Humblet wrote:
P.S.: I have no news about the recent patch to /bin/kill -f
That is because I was sure that I'd used 'kill -f' to kill windows pids
in the past and wanted to check your
On Thu, Nov 11, 2004 at 11:36:32PM -0500, Pierre A. Humblet wrote:
At 11:24 PM 11/11/2004 -0500, Christopher Faylor wrote:
On Thu, Nov 11, 2004 at 10:48:57PM -0500, Pierre A. Humblet wrote:
P.S.: I have no news about the recent patch to /bin/kill -f
That is because I was sure that I'd used 'kill
At 11:33 PM 11/11/2004 -0500, Christopher Faylor wrote:
On Thu, Nov 11, 2004 at 10:48:57PM -0500, Pierre A. Humblet wrote:
Now that 1.5.12 is out, here is a patch to fix the PROCESS_DUP_HANDLE
security hole. It uses a new approach to reparenting: the parent
duplicates the exec'ed process handle
At 12:08 AM 12/9/2003 -0500, Christopher Faylor wrote:
On Mon, Dec 08, 2003 at 11:36:01PM -0500, Christopher Faylor wrote:
I would have but the information that the fhandler contains the
controlling tty is lost by the time dup is called. Hmm. I guess I
could just check the io_handle. I'll do
On Wed, Dec 10, 2003 at 10:28:53PM -0500, Christopher Faylor wrote:
On Wed, Dec 10, 2003 at 09:54:30PM -0500, Pierre A. Humblet wrote:
At 12:08 AM 12/9/2003 -0500, Christopher Faylor wrote:
I'll work on that tomorrow.
OK, it works, but I found a few odd things.
I haven't checked in any changes
Christopher Faylor wrote:
On Sun, Dec 07, 2003 at 10:24:31PM -0500, Pierre A. Humblet wrote:
It's mostly fine (rxvt and notty) but starting the following from DOS
creates a slew of warning from the handler protection code (below).
However the shell is functional.
tty reports /dev/tty,
On Mon, Dec 08, 2003 at 10:10:10PM -0500, Pierre A. Humblet wrote:
Either myself-set_ctty should be smarter, or fhandler_tty_slave::dup
could see if it's about the ctty and simply copy it.
I stared at the set_ctty code a long time trying to understand why it
went out of its way to do the ctty
At 10:46 PM 12/8/2003 -0500, Pierre A. Humblet wrote:
At 10:28 PM 12/8/2003 -0500, Christopher Faylor wrote:
Does that solve the problem?
Yes, but now I see another one: open_fhs is off.
fhandler_tty_slave::close: decremented open_fhs -1
I have to stop for now.
One minor thing:
At 05:40 PM 12/7/2003 -0500, Christopher Faylor wrote:
On Mon, Sep 29, 2003 at 09:55:25PM -0400, Pierre A. Humblet wrote:
Here is a patch that allows to open master ttys without giving
full access to the process, at least for access to the ctty.
It works by snooping the ctty pipe handles and
On Wed, Nov 05, 2003 at 08:02:01PM -0500, Pierre A. Humblet wrote:
Ping?
This has been pending for a while. See also
http://cygwin.com/ml/cygwin-patches/2003-q4/msg3.html
I haven't forgotten about it. Unfortunately, in quick scans, the
implementation gives me heartburn. That doesn't mean
Ping?
This has been pending for a while. See also
http://cygwin.com/ml/cygwin-patches/2003-q4/msg3.html
Pierre
At 09:55 PM 9/29/2003 -0400, Pierre A. Humblet wrote:
Here is a patch that allows to open master ttys without giving
full access to the process, at least for access to the ctty.
Here is a patch that allows to open master ttys without giving
full access to the process, at least for access to the ctty.
It works by snooping the ctty pipe handles and duplicating them
on the cygheap, for use by future opens in descendant processes.
It passes all the tests I tried, but
On Mon, Sep 29, 2003 at 09:55:25PM -0400, Pierre A. Humblet wrote:
Here is a patch that allows to open master ttys without giving
full access to the process, at least for access to the ctty.
It works by snooping the ctty pipe handles and duplicating them
on the cygheap, for use by future opens
At 11:14 PM 9/29/2003 -0400, you wrote:
On Mon, Sep 29, 2003 at 09:55:25PM -0400, Pierre A. Humblet wrote:
Here is a patch that allows to open master ttys without giving
full access to the process, at least for access to the ctty.
It works by snooping the ctty pipe handles and duplicating them
54 matches
Mail list logo
