> any new development on the pipe frontier?
I haven't had as much time to work on this as I would have hoped,
due to a confluence of short-term deadlines at work and elsewhere.
But some of these projects are now done, so I have hope for an
improved rate of progress.
My plan is still to use one of
> With my current installation (Win XP SP2, Cygwin 1.5.12) it looks like I
> cannot use BitKeeper via ssh since there is a piping problem with SP2
> and Cygwin.
Could you please provide more details? Exactly what is going wrong,
and what makes you think it is due to a "piping problem"?
--
Bob
I spent a little time looking at these straces and scp -v output.
I still don't understand what's going on, but it seems to be unrelated to
the recent pipe changes. I say that because those changes only affected
select for writes on pipes, and the problem seems to be on the read side.
It looks lik
> If this is a problem with the new pipe code then maybe Bob Byrnes could
> offer some insight.
Offhand, I can't think of any way that the new pipe stuff could cause
this behavior, but I'll add this to my list of (potential) pipe-related
things to investigate and think about.
We
> > if test [-dc:/tools]; then ...
>
> ... in fact test seems to be happy with no spaces around the square
> brackets. I think it may be only if you want to use the implicit form
> of test that the brackets need to be separated with spaces from the test
> inside them, so that bash spots them as
> | Are you *sure* that you have closed *all* of the write handles to the pipe?
> | If any write handles remain open, then EOF won't be delivered to the
> | read side of the pipe.
>
> i think i did, but even if i didn't the fact that the program exit
> normally will close all open handles under wi
> I'm writing a program which need to send data to a cygwin program using
> a pipe on the stdin (actually data to compress using gzip).
>
> All is working well but at the end of the program when i close the pipe
> it seems that gzip doesn't see that the pipe has been closed and so it
> stay open.
On Sep 15, 1:18pm, Dave Korn" wrote:
-- Subject: RE: Bizarre behaviour of "make --win32"
>
> The only thing that has been going wrong here is that when make invokes
> the command through execvp it runs in the same unix-y environment that make
> is running in itself, which defies the purpose of th
On Sep 14, 4:01pm, Dave Korn wrote:
-- Subject: Bizarre behaviour of "make --win32"
>
> It appears to be using sh.exe, regardless of the --win32 flag. But if I
> add stdout redirection to the command in question, it uses cmd.exe.
>
-- End of excerpt from "Dave Korn"
On non-Cygwin, UNIX platform
...
On Sep 4, 11:51pm, Christopher Faylor wrote:
-- Subject: [ANNOUNCEMENT] Updated: cygwin-1.5.11-1
>
> Changes since 1.5.10-3:
>
> ...
>
> - Fix some problems with rsync hangs on Windows NT class systems. (Bob Byrnes)
>
-- End of excerpt from Christopher Faylor
Here are some w
On Sep 9, 9:36am, [EMAIL PROTECTED] (Joel) wrote:
-- Subject: rsync + xp sp2 failing
>
> Failed to dup/close : Socket operation on non-socket
> rsync error: error in IPC code (code 14)@
> /home/lapo/package/tmp/rsync-2.6.2/pipe.c(73)
>
-- End of excerpt from Joel
The rsync code in pipe.c looks l
This patch looks right to me.
create_selectable_pipe is the only place where CreateNamedPipe is used,
so it should completely fix the problem.
Sorry I missed this ... I don't have a win95 system to use for testing.
--
Bob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Proble
e file descriptors. Were any other
approaches considered and rejected while this code was being developed,
or was the problem not recognized at the time?
--
Bob Byrnese-mail: [EMAIL PROTECTED]
Curl Corporation phone: 617-761-1200
1 Cambridge Center, 10th Flo
13 matches
Mail list logo
