http://bugzilla.mindrot.org/show_bug.cgi?id=961
Summary: CVS annotate problems
Product: Portable OpenSSH
Version: 3.8.1p1
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ssh
AssignedTo: openssh-bugs at mindrot.org
ReportedBy: sb at dod.no
I had a problem that CVS annotate from emacs didn't work. Lines were
missing
from the output. I was told on gnu.emacs.help, that this was an SSH/CVS/libc
interaction problem that also affected other tools such as rsync, and was told
to make the CVS_RSH enviroment variable point to the following bourne shell
script:
#!/bin/sh
(ssh "$@" 2>&1 1>&3 | cat) 3>&1 1>&2
Using the script fixed the problem for me, but it would be nice not to need it.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org writes:> http://bugzilla.mindrot.org/show_bug.cgi?id=961> I had a problem that CVS annotate from emacs didn't work. Lines were > missing from the output. I was told on gnu.emacs.help, that this was > an SSH/CVS/libc interaction problem that also affected other tools > such as rsync, and was told to make the CVS_RSH enviroment variable > point to the following bourne shell script: > > #!/bin/sh > (ssh "$@" 2>&1 1>&3 | cat) 3>&1 1>&2 > > Using the script fixed the problem for me, but it would be nice not to > need it.FYI. Both cvs-1.11.18 (the stable branch release) and cvs-1.12.10 (the feature branch release) have a workaround for your problem. The difficulty is that SSH puts stdout into non-blocking mode via a redirection of stderr. In turn, this may lead to fwrite() and/or fflush() failing with EAGAIN which was not expected by previous versions of CVS (rsh does not exhibit this misbehavior). I agree that it would be nice if SSH did not make stdout non-blocking just because stderr has been redirected to it. -- Mark
http://bugzilla.mindrot.org/show_bug.cgi?id=961 ------- Additional Comments From mdb at juniper.net 2004-12-10 20:09 ------- Both cvs-1.11.18 (the stable branch release) and cvs-1.12.10 (the feature branch release) have a workaround for your problem. The difficulty is that SSH puts stdout into non-blocking mode via a redirection of stderr. In turn, this may lead to fwrite() and/or fflush() failing with EAGAIN which was not expected by previous versions of CVS (rsh does not exhibit this misbehavior). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=961
------- Additional Comments From djm at mindrot.org 2004-12-10 20:46 -------
Created an attachment (id=751)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=751&action=view)
Return stdio to blocking before executing shell/command
I don't recall any of the CVS developers reporting this, but anyway - this
patch resets std{in,out,err} to blocking mode before the command or shell is
executed.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=961 ------- Additional Comments From djm at mindrot.org 2004-12-13 12:58 ------- hm, this may be a bug in Linux's socket or tty code - sshd never touches the child's fds. This patch therefore just prints: debug3: fd 0 is not O_NONBLOCK debug3: fd 1 is not O_NONBLOCK debug3: fd 2 is not O_NONBLOCK (tested: Linux, OpenBSD, Solaris 10) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.