kevin wang <[EMAIL PROTECTED]> writes: > > The problem is that in a standard configuration: > > > > --stderr-> -------------stderr------------> > > / \ / / \ > > CVS Server ssh CVS client tty > > \ / \ / \ / > > --stdout-> --stdout-> --stdout-> > > > > Note that since CVS didn't access the stderr of its child process, ssh, > > the child process gets a clone of the parent process' stderr descriptor > > and ssh and the CVS client end up sharing the tty's standard error. > > > > Now, when the user redirects stderr to stdout, say, to redirect the > > output to a file (e.g. CVS_RSH=ssh cvs diff >tmp.diff 2>&1), you get the > > following configuration: > > This may sound silly, but as a temporary workaround, can't you: > > CVS_RSH=ssh cvs diff >tmp.diff 2>tmp.diff
Sure (in append mode), or, even easier, don't use 2>&1 at all. Or do what I do, and set CVS_RSH to a shell script which invokes ssh with 2>/dev/null. That always works--if ssh fails you can just run it by hand to see the error message. The problem is that people use cvs 2>&1 with CVS_RSH set to ssh, and expect it to work, and think it is a CVS bug when it fails. Educated users don't have a problem. Ian _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
