Re: Bug located in `process-connection-type' (even in 21.1.14) (WAS: Re: [Adrian Aichner <adrian@xemacs.org>] Re: PCL-CVS shows Parser Errors in *cvs* buffer)

>>>>> "Jarl" == Jarl Friis <jarl(a)diku.dk&gt; writes: Jarl> Jarl Friis <jarl(a)diku.dk&gt; writes: >> Jarl Friis <jarl(a)diku.dk&gt; writes: >> >> > >> > I must admit that the problem seems deeper than just cvs gives >> > non-parseable feedback something lurking in either the *usage* of >> > xemacs network features within pcl-cvs or the implementation of the >> > XEmacs network features. >> >> Sorry, it seem not to be related to networking, since pcl-cvs is not >> directly using the XEmacs network features, but just invokes cvs as a >> process, nevertheless I consider it a XEmacs bug, but merely related >> to the `start-process' function. Jarl> I have made a very small program that demonstrates the Jarl> location of the bug. Essentially it is setting the variable Jarl> `process-connection-type' to nil that causes trouble. In the Hi Jarl, thanks for narrowing in on this!

I am using a slightly modified version which names the process buffers uniquely so I can diff them afterwards.

Could you please do the same on send in the diffs?

I am not getting any diffs in cvs output in native Windows 2000 XEmacs on all of of XEmacs packages module monster!

On a second try I got following diff which I think is unrelated (waiting for a lock in CVS): --- C:\DOCUME~1\AICHNE~1\LOCALS~1\Temp\ediffsYA2he Thu Jan 24 23:23:03 2002 +++ C:\DOCUME~1\AICHNE~1\LOCALS~1\Temp\ediffsYADsk Thu Jan 24 23:23:03 2002 ＠＠ -15338,6 +15338,8 ＠＠ Sticky Options: (none) cvs server: Examining xemacs-packages/ilisp +cvs server: [23:05:53] waiting for cvs's lock in /pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp +cvs server: [23:06:23] obtained lock in /pack/xemacscvs/XEmacs/packages/xemacs-packages/ilisp =================================================================== File: .cvsignore Status: Up-to-date ＠＠ -31917,4 +31919,4 ＠＠ Sticky Options: (none) -Process mycvs finished +Process mycvs<1> finished Jarl> examples, please modify the hardcoded strings as necessary. Jarl> The first one makes a cvs status using pipes, which creates spurious Jarl> output in " *mycvs-tmp*" buffer: Jarl> (let ( Jarl> (process-connection-type nil) ; Use a pipe, not a pty. Jarl> (default-directory (cvs-expand-dir-name "~/projects/eicq")) Jarl> ) Jarl> (apply 'start-process "mycvs" (get-buffer-create " *mycvs-tmp*") "cvs" '("-f" "status")) Jarl> ) Jarl> The second one uses a pty instead, and sends the password "manually", Jarl> which works! Jarl> (let ( Jarl> (mypassword "PaSsWoRd");;insert a password here Jarl> (process-connection-type t) ; Use a pipe, not a pty. Jarl> (default-directory (cvs-expand-dir-name "~/projects/eicq")) Jarl> ) Jarl> (apply 'start-process "mycvs" (get-buffer-create " *mycvs-tmp*") "cvs" '("-f" "status")) Jarl> (process-send-string "mycvs" (concat mypassword "\n")) Jarl> ) Jarl> Now the usage of `process-connection-type' is not to be found in Jarl> `start-process' so I guess it is used in `start-process-internal' Jarl> which is implemented in C, will someone please take over from here? Ah, xemacs-21.5\src\process-unix.c allocates a pty for process-connection-type t, while xemacs-21.5\src\process-nt.c is not doing anything with process-connection-type! This is probably why I don't see this kind of problem.

In xemacs-21.5\src\process-unix.c there is ... static int unix_create_process (Lisp_Process *p, Lisp_Object *argv, int nargv, Lisp_Object program, Lisp_Object cur_dir) { int pid; int inchannel = -1; int outchannel = -1; /* Use volatile to protect variables from being clobbered by longjmp. */ volatile int forkin = -1; volatile int forkout = -1; volatile int pty_flag = 0; if (!NILP (Vprocess_connection_type)) { /* find a new pty, open the master side, return the opened file handle, and store the name of the corresponding slave side in global variable pty_name. */ outchannel = inchannel = allocate_pty (); } Jarl> Now when the bug tracks into the C-code I guess it is relevant with Jarl> system information, how can I have XEmacs collect all the information Jarl> necessary for this? In short I run XEmacs 21.1.14, 21.5.4, linux, If necessary/possible, please install the latest net-utils package (>= 1.23) and then use Help->Send Bug Report... or M-x report-emacs-bug as suggested in http://www.xemacs.org/Debug/index.html

Jarl> $ gcc -v Jarl> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs Jarl> gcc version 2.95.3 20010315 (SuSE) Jarl> Will someone please take over from here as I am not familiar with Jarl> XEmacs C code? Thanks for tracking this down, Jarl. This should bring us a lot closer to a solution!

I'll be skiing for a week starting saturday.

I hope somebody will take this up meanwhile.