[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS Feature Branch - version - cannot write to stdout
From: |
Mark D. Baushke |
Subject: |
Re: CVS Feature Branch - version - cannot write to stdout |
Date: |
Sat, 09 Oct 2004 12:25:50 -0700 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Conrad,
The error is arising from handle_m() in client.c The value of the select
is either 0 (this should not happen as we are not specifing a timeout)
which means that the select() timed-out or -1 which means that there
were no ready descriptors.
I have known of problems with SSH that had some interoperability issues
which is what I originally suspected when I saw your message. However,
if you are using :pserver:, then I would not have expected that kind of
problem.
The 'No error' means that errno == 0 after the select() call.
Looking here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/select_2.asp
I see that it may be possible to get more information if we examine the
SOCKET_ERROR and that WSAGetLastError may be used to find the most
recent socket error.
If you modify the handle_m() function to grok the Windows way to get
more information and print it, something like this:
static void
handle_m (char *args, int len)
{
fd_set wfds;
int s;
/* In the case where stdout and stderr point to the same place,
fflushing stderr will make output happen in the correct order.
Often stderr will be line-buffered and this won't be needed,
but not always (is that true? I think the comment is probably
based on being confused between default buffering between
stdout and stderr. But I'm not sure). */
fflush (stderr);
FD_ZERO (&wfds);
FD_SET (STDOUT_FILENO, &wfds);
s = select (STDOUT_FILENO+1, NULL, &wfds, NULL, NULL);
if (s < 1)
{
int sockerr = WSAGetLastError();
const char *msg = "unknown";
perror ("cannot write to stdout");
switch (sockerr)
{
case WSANOTINITIALISED:
msg = "WSANOTINITIALISED";
break;
case WSAEFAULT:
msg = "WSAEFAULT";
break;
case WSAENETDOWN:
msg = "WSAENETDOWN";
break;
case WSAEINVAL:
msg = "WSAEINVAL";
break;
case WSAEINTR:
msg = "WSAENETDOWN";
break;
case WSAEINPROGRESS:
msg = "WSAEINPROGRESS";
break;
case WSAENOTSOCK:
msg = "WSAENOTSOCK";
break;
}
printf(stderr, "WSAGetLastError == %s\n", msg);
}
fwrite (args, len, sizeof (*args), stdout);
putc ('\n', stdout);
}
we may have a better idea of what is happening that needs to be changed.
Thanks,
-- Mark
Conrad T. Pino <Conrad@pino.com> writes:
> Hi Mark,
>
> > From: Mark D. Baushke
> >
> > Hi Conrad,
> >
> > Could you provide a bit more information?
>
> Yes I'd be glad to do so.
>
> > Which client/server protocol are you using?
> >
> > * :ext: over ssh
> > * :ext: over rsh
> > * :pserver: tunneled over ssh
> > * :pserver:
>
> Simple ":pserver:" to a host on my LAN.
>
> > I presume that the client is a Windows cvs top-of-tree and that the
> > server is a vanilla cvs 1.11.17 cvs distribution.
>
> Client: Yes, top of tree it is.
>
> Server: Yes, it the vanilla cvs 1.11.17 distribution built from source
> on the target platform (Solaris 8 Intel Edition).
>
> > Do you happen to know the OS of the server?
>
> Solaris 8 Intel Edition.
>
> > For myself, using FreeBSD 4.2-RELEASE as the server OS and FreeBSD
> > 4.2-RELEASE as the client OS, :ext: over ssh, I get the following:
> >
> > bash$ ./cvs version
> > Client: Concurrent Versions System (CVS) 1.12.9.1 (client/server)
> > Server: Concurrent Versions System (CVS) 1.11.17 (client/server)
> > bash$
>
> My first example was with my local server via plain ":pserver:".
>
> > Using FreeBSD 4.2-RELEASE as the client OS, and cvshome.org as the
> > server, :pserver: tunneled over ssh, I get the following:
> >
> > bash$ ./cvs version
> > Client: Concurrent Versions System (CVS) 1.12.9.1 (client/server)
> > Server: Concurrent Versions System (CVS) 1.11.15-scast-vc-1.5.2
> > (client/server)
> > bash$
>
> Here's the example with cvshome.org via ":pserver:" SSH tunnel:
>
> H:\cvs-1.12>WinDebug\cvs version
> Client: Concurrent Versions System (CVS) 1.12.9.1 (client)
> Server: cannot write to stdout: No error
> Concurrent Versions System (CVS) 1.11.15-scast-vc-1.5.2 (client/server)
>
> H:\cvs-1.12>
>
> > I do not happen to have any Windows clients to use for testing...
>
> Could you make constructive use of Windows 2000 Server platform accessible
> remotely via SSH tunneled telnet?
>
> > -- Mark
>
> Conrad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFBaDs93x41pRYZE/gRAoXoAJ90o2f+ucAWL2uYcE8PQzPZlE3vKQCfYvOu
U2v0MZxA/M7jaAOp+xXgc9E=
=Zkgd
-----END PGP SIGNATURE-----
- CVS Feature Branch - version - cannot write to stdout, Conrad T. Pino, 2004/10/09
- Re: CVS Feature Branch - version - cannot write to stdout, Mark D. Baushke, 2004/10/09
- RE: CVS Feature Branch - version - cannot write to stdout, Conrad T. Pino, 2004/10/09
- Re: CVS Feature Branch - version - cannot write to stdout,
Mark D. Baushke <=
- Re: CVS Feature Branch - version - cannot write to stdout, Derek Robert Price, 2004/10/09
- RE: CVS Feature Branch - version - cannot write to stdout, Conrad T. Pino, 2004/10/11
- Re: CVS Feature Branch - version - cannot write to stdout, Mark D. Baushke, 2004/10/11
- RE: CVS Feature Branch - version - cannot write to stdout, Conrad T. Pino, 2004/10/11
- Re: CVS Feature Branch - version - cannot write to stdout, Mark D. Baushke, 2004/10/11
- Re: CVS Feature Branch - version - cannot write to stdout, Mark D. Baushke, 2004/10/20
- RE: CVS Feature Branch - version - cannot write to stdout, Conrad T. Pino, 2004/10/22
- Re: CVS Feature Branch - version - cannot write to stdout, Mark D. Baushke, 2004/10/22
- RE: CVS Feature Branch - version - cannot write to stdout, Conrad T. Pino, 2004/10/22
- RE: CVS Feature Branch - version - cannot write to stdout, Conrad T. Pino, 2004/10/22